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ABSTRACT 


AFVS (Automated Verifiction of Flight Software) is a collection of 
tools for analyzing source programs written in FORTRAN and AED. AVFS 
aids in improving the quality and the reliability of flight software by 
providing: 

• Indented listings of source programs 

• Static analysis to detect inconsistencies in the use 
of variables and parameters 

• Automated documentation 

• Instrumentation of source code 

• Retesting guidance 

• Analysis of assertions 

• Symbolic execution 

• Generation of verification conditions 

• Simplification of verification conditions 

This manual describes how to use AVFS in the verification of 
f light so f tware • 

AVFS is one important component of a Digital Flight Control System 
Verification Laboratory (DFCSVL) which has been established at NASA Ames 
Research Center, Moffett Field, California* The DFCSVL includes a PDP 
11/60 processor and a palletized CAPS 6 based digital flight control 
system* Most of the AVFS files have been hosted in the Univac 1100 
computer system in Santa Clara, California. Access to these files from 
the DFCSVL is provided via a direct link connecting the PDP 11/60 and 
the Univac 1100. 
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1 INTRODUCTION 

AVFS (Automated Verification of Flight Software) is a collection 
of tools for analyzing flight software. AVFS is one important component 
of a Digital Flight Control System Verification Laboratory (DFCSVL), 
pictured in Figure 1 (DFCSVL block diagram shown in Figure 1.1), which 
has been established at NASA Ames Research Center, Moffett Field, 
California. 



Figure 1.1 DFCS Verification Laboratory Block Diagram 
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The DFCSVL includes a PDP 11/60 processor (the environment 
computer) and a palletized CAPS 6 based digital flight control system 
(flight computers, pilot information panel, and sensor/acutator models). 
Most of the AVFS tools have been hosted in a Univac 1100 computer system 
(the software tools computer). Access to the AVFS tools from the 
environment computer is via a high speed data link over a telephone 
line. 


AVFS analyzes source programs written in FORTRAN or AED (Automated 
Engineering Design). AED is an Algol-like programming language origin- 
ally developed at MIT for the U.S. Air Force. 

AVFS aids in improving the quality and reliability of flight 
software by providing: 

• Indented listings of source programs 

• Static analysis to detect inconsistencies in the use of 
variables and parameters 

• Automated documentation 

• Instrumentation of source code 

• Retesting guidance 

• Analysis of assertions 

• Symbolic execution 

• Generation of verification conditions 

• Simplification of verification conditions 

AVFS allows the addition of assertions to a program. These asser- 
tions make it possible for AVFS to include (1) a more comprehensive 
static analysis than is possible without the use of assertions, (2) more 
useful results from execution testing, and (3) formal verification by 
the generation and simplification of verification conditions. Figure 
1.2 shows the various AVFS capabilities. 
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Figure 1.2. AVFS Capabilities 


1.1 TESTING AND VERIFICATION SEQUENCE 

The traditional method of detecting errors is limited to those 
errors which surface at compilation and during execution. AVFS, how- 
ever, provides assistance to the user through system integration, 
testing, documentation, program verification, and maintenance. 

As flight software is being written, the programmer can submit one 
or more modules for analysis by AVFS so that errors will be detected 
before they propagate through the entire system. Assertions should be 
included in the source text, as a valuable part of the analysis relies 
on information about the variables that are supplied in the assertions. 
Figure 1.3 illustrates the steps to be taken in validating a program 
with AVFS. 
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1.1.1 Syntax Errors 

The first step in verifying a program is the elimination of syntax 
errors. If the source is written in FORTRAN, the FORTRAN compiler 
should be used to provide a listing and a diagnostic report. If the 
source is written in AED, the AED compiler should be used in a similar 
manner . 

1.1.2 Static Analysis 

Once syntax errors found by the compiler have been corrected, the 
source code is ready for the second step in verification (Fig. 1.2), 

which is static analysis to detect consistency errors. It is not 

necessary to wait for integration of the entire software system to begin 
using AVFS; one module at a time can be submitted for static analysis. 
By doing this errors will be detected as early as possible. The static 
analysis (which will be described in detail in Sec. 4) examines the 
source code for the following inconsistencies: 

• Physical-units errors: operations on variables whose 

asserted physical units (feet, kilograms, etc.) do not 

correspond to actual use. 

• Set/use errors: variables which are used before they are 

set to a value, or set to a value and then not used. 

• Asserted/ actual use errors: parameters which are used as 

output variables when they have been restricted, by 

assertions, to being input variables, or vice-versa. 

• Graph errors: unreachable statements which cannot be 

executed because they are structurally disconnected from the 
main program. 

• Loop errors: uninitialized loop variables. 
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• Poor practice errors: unused parameters, constant parame- 

ters, double parameters, expression parameters, function 
parameters* 

1.1.3 Execution Testing 

When a software system is fully integrated and the inconsistencies 
found by static analysis have been corrected, the next step is execution 
testing. When a program is ready for this step, AVFS offers assistance 
before, during, and after execution. 

In preparation for testing, AVFS analyzes the program to determine 
the paths through the program. AVFS instruments the program by auto- 
matically inserting probes at appropriate points in the program to 
measure testing coverage, to check on assertion violations, or to trace 
variables in the code. During an execution test, these probes record 
information which can be used to report on execution coverage, assertion 
violations, execution time, and the value of important variables. When 
parts of a program have been found to be untested, another AVFS tool can 
provide help in selecting test cases to exercise these untested paths of 
the program by delineating the unreached portions of code. During the 
entire testing process, AVFS can be thought of as a partner, supplying a 
wide variety of automated aids to comprehensive testing. 

1.1.4 Formal Verification 

Following the correction of any errors found during static 
analysis and execution testing, the tested program is ready for formal 
verification, which is the final step in verifying a program (Fig. 1.2). 
When a program is executed, numerical data is supplied as input. The 
procedure for formal verification is to execute the program "symbolic- 
ally," that is, using symbols as input data rather than specific 
numbers. The program is then verified or "proved" correct for a wider 
range of its variables then it is practical to assign to them during 
execution. 
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AVFS allows the symbolic execution of variables, expressions, or 
assertions* The symbolic execution of variables or expressions can be 
used to verify that a module's output is the same as the formula it has 
been specified to compute* The symbolic execution of assertion results 
in what has been termed verification conditions. By showing that the 
verification conditions for a module are true, it is said that the 
module has been formally verified with its assertions. 

1.2 USER'S MANUAL ORGANIZATION 

This manual describes how to use AVFS as an aid from the beginning 
to the end of the software development cycle. Information is presented 
in the order that the user is expected to need it. Section 2 is an 
overview of the type of aid AVFS provides. Section 3 explains how to 
use AVFS (commands, files, etc.). Section 4 describes each of the AVFS 
capabilities. Section 5 lists AVFS constraints. When the user's program 
has been instrumnted by AVFS and is ready for testing, special commands 
are needed to generate execution coverage analysis reports. These 
commands are described in Sec. 6. 

Appendix A contains a summary of the AVFS commands. Tables 
listing the files used in AVFS processing are in Appendix B. * Job 
streams for the Univac 1110 in Appendix C. 
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2 


AVFS OVERVIEW 


This section contains an ovreview of the way in which AVFS can aid 
the user not only in creating the code but during testing and documen- 
tation. The information presented here about what AVFS does is very 

general; the following sections contain more complete details of the 
full power of AVFS and how to use it. 

Figure 2.1 shows how AVFS fits into the software development cycle 
to augment software analysis and testing. The additional features are 
indicated by diagonal lines. The user’s source code can be analyzed by 
AVFS and the results will be presented in reports which help the user 
decide if acceptance criteria are met. AVFS can also instrument source 
code prior to execution to provide a measure of test coverage, to 
provide automatic checks on the behavior of a program and to trace 
module variables. AVFS can be used to perform formal verification of 
formulas and assertions via symbolic execution. 

The usual program analysis and testing sequence is shown in Fig. 
2.2. AVFS analyzes either FORTRAN or AED code and generates the 
following information: 

• An enhanced listing of each module 

• A static analysis of each module 

• Interface data and module relationships 

• Information about each module in brief form 

• Structural information about each module 

• Trace information about variables 

• Assertion violations 

• Assistance in retesting 

• Symbolically executed formulas 

• Verification conditions 
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Figure 2.1. Software Verification Augmented by AVFS 
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Figure 2.2. Sequence of Source Program Analysis, 
Test, and Formal Verification 
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The TRACE, ASSERT, and INSTRUMENT functions prepare the user’s program 
for execution testing. Utilizing the knowledge it obtains about the 
structure of the program, AVFS can instrument the user’s program by 
inserting software probes in each path. In addition, INPUT and OUTPUT 
assertion statements which list selected variables can be added to a 
module and AVFS will automatically generate code to output the values of 
these variables during execution of the modules. ASSERT statements 
which place conditions on selected variables will cause AVFS to auto- 
matically generate code to report on assertion violations during module 
execution. 

When an instrumented module is executed, data is recorded each 
time a path is traversed. For FORTRAN programs, the path data is stored 
on a file for later analysis by a coverage analyzer on the Univac. For 
AED programs, the path data is stored in the CAPS memory for later 
analysis by a coverage analyzer on the PDP 11/60. In either case, these 
reports show the user where to focus retesting. AVFS can make further 
tests easier by furnishing a Reaching Set Report to list the source code 
on paths which were not executed. The user can then determine the 
values that must be assigned to the variables on these paths in order to 
reach the set of untested statements. The program is executed again and 
the procedure is repeated until the user is satisfied that testing is 
complete . 

After execution testing, the user can formally verify the program 
by symbolically executing expressions or assertions. This process will 
result in formulas which can be checked against a specification or in 
verification conditions which can be proved to be valid. During the 
formal verification process, the user will often alter the program or 
assertions to validate the program until verification is complete. 

During analysis of a program by AVFS, an interface file can be 
generated and stored. The interface file is the key to multiple module 
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interface checks. The interface report lists each module name which has 
been anlayzed and indicates changes in interface properties, such as 
parameters added or deleted, changes in type or use of parameters, 
changes to common, and changes to invocations. 

FORTRAN and AED programs can be made up of single or multiple 
modules. In the analysis of a FORTRAN program, the modules are placed 
in a single data file and analyzed together with a single execution of 
the tool. In the analysis of an AED program, the modules are placed in 
elements of a program file and analyzed with separate executions of the 
tool for each module. Information for multiple module reports is 
gathered during the analysis of the separate modules and printed after 
all the modules have been analyzed. The analysis of a large FORTRAN 
program often results in a large listing for which a report index has 
been provided. An example of a report index is shown in Fig. 2.3. 
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REPORT INDEX... 


PAGE 


MULTI-NODULE REPORTS 


INTERFACE CHANGES 1 

INVOCATION SUMMARY 14- 17 

COMMON MATRICES 18- 26 

I/O STATEMENTS 27 

CROSS REFERENCE 28 

SUBROUTINE PTRSTR < MODULE. I STMT, IRETRN ) 

SYMBOLS 2 

CROSS REFERENCE 3 

INVOCATION SPACE 4 

INVOCATION BANDS 3 

SUBROUTINE SDBASA ( MODULE, I STMT, IRETRN ) 

SYMBOLS A- 8 

CROSS REFERENCE 9- 12 

INVOCATION SPACE 13- 14 

INVOCATION BANDS 13 

CROSS REFERENCE 29- 31 


... WRITING INTERFACE LIBRARY 
. . . 4073 UCRDS URITTEN 


Figure 2.3. Report Index 
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USING AVFS 


AVFS is a software system which reads as input a user's source 
program in order to perform a number of functions on the source program 
(Fig. 3.1). The source program may be written in FORTRAN or AED and may 
be read into AVFS directly from a standard input device (card reader, 
terminal, or tape) or from a previously prepared source text file. 

The user tells AVFS which functions to perform through a series of 
commands. These command can be sent to AVFS via a standard input device 
or from a previously prepared command text file. 

For FORTRAN, the analysis of several modules can be accomplished 
if they are part of a single data file. For AED, modules are stored as 
elements of a program file. 
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Figure 3*1. AVFS Processing 
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During an Interface run, the source code is analyzed and stored in 
a data base known as the interface file. The interface file stores the 
module name and information on its interface to other modules such as 
information on invoked subprograms and commons. 

During an instrumentation run, the structure of the source code is 
analyzed for the paths between the decision points. Each module's first 
path always starts at program entry and includes all the statements 
until a decision or the end of the routine is reached. These paths form 
the basis for instrumentation and subsequent execution coverage anal- 
ysis. AVFS uses the path information to produce reports. 

AVFS can operate on the source code which it reads during its run 
and produce reports. AVFS can also produce reports using information 
(from previously processed programs) that is in the data base called the 
interface file. The interface file contains the external characteris- 
tics of previously analyzed programs and allows reports to be generated 
for only the modules under anlaysis. This allows re-analysis of a 
changed system at a far lower cost than if the complete system were re- 
analyzed. It is a good practice to use separate interface files for 
separate software projects. 

The logical unit numbers for the files are shown in brackets in 
Fig. 3.1. Appendix B has a list of all the file names and numbers used 
by AVFS. 

Before submitting source text for analysis, the user should take 
certain preliminary steps : 

1. The source text should be compiled by a FORTRAN or AED 
compiler to confirm it is free of syntax errors. 

2. The program should be executed if it will be dynamically 
tested. 
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AVFS processing is specified by commands* For FORTRAN, either an 
OPTION or REPORT command is required for each run. For AED, a separate 
XQT command is required for each function. Other commands are used to 
assign appropriate files, to change default values, or to make certain 
specifications. The order of commands is important to AVFS. When 
multiple comnands are given to the FORTRAN AVFS, the following order 
must be observed: 

RESTART. 

EXPAND. 

FILE, PUNCH =• <file number>. 

INSTRUMENT, PUNCH, PROBE, (<f ile number>) . 

FIRSTLINE » (<run stream command>). 

OPTION =» <option list>. 

REPORT « <report list>. 

FOR MOUDLES » (<name !>,<name 2>, ... )• 

TESTBOUND , MODULE =* (<name>) , STATEMENT - <number>. 

REACHING SET, MODULE - (<name>) ,T0 * <DD-path number>, 

FROM =* <DD-path number >{, ITERATIVE) . 

Each command consists of a sequence of terms separated by a comma or an 
equal sign. These commands—one to a card, or input record — are free 
form; blanks are ignored. The comnands may be abbreviated by using the 
first four letters of the first word in the command. The names of the 
options also may be abbreviated in the same way. 

Table 3.1 shows the conditions under which the RESTART or EXPAND 
commands should be used. The first line gives the case where it is 
desired to analyze new source without using an existing interface file. 
This case covers the situation of a first run of the tool and the x 
situation tfien it is desired to analyze a module in isolation without 
using an interface file. In this case, neither command is used. Page 
C-l contains a sample job control for this case. 
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TABLE 3.1 

EXPAND - RESTART COMMAND CONDITIONS 


Source? 

Existing Interface File? 

Command to Use 

Yes 

No 


Yes 

Yes 

EXPAND 

No 

No 

Do Nothing 

No 

Yes 

RESTART 


The second line gives the case when there is an existing interface 
file and there is new source code to be analyzed by the tool. In this 
case, the EXPAND command is used. Page C-2 contains a sample job 
control for this case. 

The third line gives a case that should not occur. If there is 
neither source nor an interface file to process, then no commands should 
be given. 

The fourth lines gives the case where there is no new source, but 
it is desired to reanalyze an existing interface file which was created 
from a previous execution of the tool. Page C-3 contains a sample job 
control for this case. 

The FILE, INSTRUMENT, and FIRSTLINE commands are used with the 
INSTRUMENT or INPUT/OUTPUT options. Table 3.2 shows the conditions 
under which these commands should be used. Normally, neither the FILE 
command nor the INSTRUMENT command is used. The FIRSTLINE command is 
usually used. 
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The FILE command is used to change the default file number for 
where the tool sends the instrumented code* If unit 9 is suitable for 
the instrumented code, the FILE command need not be specified. The job 
control sequence shown on page C-4 instruments a source program and 
places the instrumented source one unit 10. 

The INSTRUMENT command is used to change the default file number 
for where the tool collects data during execution of the instrumented 
code. If unit 12 is suitable for the data collection file, the INSTRU- 
MENT command need not be used. The job control control sequence shown 
on page C-4 instruments a source program to collect data on unit 20. 

The FIRSTLINE command is used to insert the FORTRAN compilation 
Univac job control between modules. Each module on the file must have a 
job control card to cause compilation and storage of the relocatable 
element in a program file. In the example shown on page C-4, the ASCII 
compiler, FTN, is invoked to store the relocatable element in the 
temporary program file, TPF$. 

The OPTION command is used to select from one of many possible 
processing options for the tool. Examples of the use of the STATIC 
option are shown in C-l, C-2, and C-3. Examples of the use of the 
INSTRUMENT and LIST options are shown in C-4. The various options are 
discussed In detail in Sec. 4. 

The REPORT command is used to obtain the flowgraph or picture 
report under the DOCUMENT option. An example of the use of this cotnnand 
is given in C-5. 
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TABLE 3.2 

FILE - INSTRUMENT - FIRSTLINE 
COMMAND CONDITIONS 


Is unit 9 suitable for the 

Yes 

do not use FILE command 

instrumented code output 

No 

use FILE conmand 

by the tool? 




Is unit 12 suitable for the 

Yes 

do not use INSTRUMENT command 

data collected during an 

No 

use INSTRUMENT conmand 

execution of instrumented 



code? 




Do Univac job control cards 
need to be inserted between 
modules? 


Yes use FIRSTLINE command 

No do not use FIRSTLINE conmand 


The FOR MODULES command is used to instrument or report on 
selected modules from among a group of modules that have been read into 
the tool. Page C-6 shows an example where three modules named MAIN SORT 
and CALC are statically analyzed from among the modules input to the 
tool. 


The TESTBOUND command is used in the instrumentation of a program 
when it is desired to specify a statement at which a test case to be 
counted. When the TESTBOUND command is omitted, the test boundary is 
taken to be the first statement in the main program. Page C-4 shows an 
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example where the TESTBOUND command was used to specify that line 10 of 
the main program is defined as a test case boundary. 

The REACHING SET comnand is used after an instrumentation run has 
found that some or several paths were not executed. The REACHING SET 
command is used together with the REACHING SET option to cause a set of 
paths to be printed between the two specified paths.. A user can then 
concentrate on causing these paths to be executed. Page C-7 shows the 
use of the REACHING SET command to list the paths between path 3 and 
path 7 in Module SORT. 

3.1 INTERFACE FILE 

3.1.1 FORTRAN 

The FORTRAN AVFS differentiates between when source code is being 
read into the tool and when the interface file is being used by itself 
to produce intermodule reports. 

• On the first run of a FORTRAN AVFS, save the interface file 
that is created on unit 8. Do not use the RESTART or EXPAND 
command on the first run. 

• On the second and subsequent runs of a FORTRAN AVFS, assign 
the saved file to unit 11. If there is just to be a re- 
analysis of the file, use the RESTART command. If there is 
new or changed source to be read in, use the EXPAND conmand 
instead. A new interface file will be created on unit 8. 
This file may be saved. 

3.1.2 AED 

The AED AVFS interface analysis tool will read an old interface 
file from unit 8 and new source from unit 5. If there is new source, 
the Interface file will be generated on unit 11. The invocation of the 
AED interface analysis requires no additional conmands. 
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3.2 INSTRUMENT FILE 

The primary function of several AVFS tools is to produce source 
output on unit 9 (FORTRAN) or unit 30 (AED). This source normally goes 
to a temporary file (which may be saved after the AVFS run). If unit 9, 
the default assignment for the source output file is not appropriate for 
a FORTRAN program (usually because the program uses that unit for its 
own purposes); it may be reassigned with the command 

FILE, PUNCH - <file-number>. 

where <f ile-number> is the desired file number. (See Appendix B for 
assigned file numbers). 

In AED, it is never necessary to change the file number, because 
the AED program will not be executing on a Univac. 

3. 3 FIRSTLINE 

When a FORTRAN program is to be INSTRUMENTED, the user's instru- 
mented source program will be written to unit 9. The user may use the 
command , 

FIRSTLINE » (<run stream command>) 

to specify a Univac run stream comnand that will be added as the first 
line of every element of the source program. 

\ 

For example, when a FORTRAN source program will be instrumented, 
then compiled and executed, the user could use the command 

FIRSTLINE - (@F0R<I TPF$.+). 

AVFS will insert the Univac command, 

@F0R,I TPF$.<element name> 

as the first line of each element with the appropriate element name 
following TPF$. If the Univac FTN compiler is being used, the command 
could be 

FIRSTLINE - (@FTN,I TPF$.+). 
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If the source code is written in AED, the FIRSTLINE command is not 
needed. Each AED element is in its own program element and is processed 
separately. 

3.4 PROCESSING OPTIONS 

The processing functions for FORTRAN are handled by the OPTION 
conmand. The processing functions for AED are handled by different 
execute commands. The possible options are as follows: 


FORTRAN 

AED 

LIST 

GRC*LIST.LIST 

STATIC 

GRC*STATIC. STATIC 

DOCUMENT 

GRC*CROSS. CROSS 
GRC*SYMBOL. SYMBOL 
GRC*INVOKE. INVOKE 


GRC*TREE. TREE 
GRC*DEPEND. DEPEND 
GRC*GLOBAL. GLOBAL 

SUMMARY 

GRC*PROFILE. PROF ILE 

UNITS 

GRC*UNITS. UNITS 

INPUT/OUTPUT 

GRC*TRACE. TRACE 

ASSERT 

GRC*ASSERT. ASSERT 

INSTRUMENT 

GRC*INST. INST 

REACHING SET 

GRC*REACH. REACH 

VCG 

GRC*VCG. VCG 


• LIST - Produces an enhanced listing of each module 

• STATIC - Produces a static analysis of each module 

• DOCUMENT - Produces six reports for each module; the cross 

reference, symbol tables, dependence matrix, calling- 
tree, invocations report, and global cross reference 
reports (for AED, the reports are requested separ- 
ately) 


23 



• SUMMARY - Provides an analysis of statements 

• UNITS - Checks for consistency of units that have been 

defined in a UNITS assertion 

• INPUT/OUTPUT - Translates INPUT/OUTPUT assertions 

• ASSERT - Translates logical assertions 

• INSTRUMENT - Instruments the source code 

• REACHING SET - Provides assistance in path identification 

• VCG - Symbolic execution and verifictaion condition gener- 

ation 

In the FORTRAN tools, the command form is 
OPTION{S> =■ <option list> 

where more than one option may be specified. There must be at least one 
option. Multiple options may be separated by conmas on a single 80- 
character line. More than one OPTION line may be submitted. Detailed 
descriptions of each option with examples of the reports that the option 
produces may be found in Sec. 4. 

In the AED tools, the Univac command is 
@XQT option 

Separate commands may be given to obtain multiple reports in a single 
job. The examples of each AED option may be found in Sec. 4. 

3.5 REPORT 

Selection of individual reports to be produced can be accomplished 
by the REPORT comnand for FORTRAN programs. The separate reports for 
AED are handled by different execute commands. The possible reports are 
as follows: 
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REPORT 

FORTRAN 

AED 

NAME 

COMMAND 

COMMAND 

COMMONS 

CO 


PROFILE 

PR 

GRC*PROFILE. PROF ILE 

INVOCATIONS 

L 

GRC*INVOKE. INVOKE 

COMMON MATRICES 

CO/E 


CALLING TREE 

B 

GRC*TREE.TREE 

SPACE 

SP 

GRC*DEPEND. DEPEND 

SYMBOLS 

SY 

GRC*SYMBOL. SYMBOL 

I/O STATEMENTS 

R 


CROSS 

CR 

GRC*CR0SS. CROSS 

FLOWGRAPH 

PI 

GRC*F LO W . FLOW 


In the FORTRAN tools, the command form is 
REPORT - Creport list> 

where more than one report may be specified. Blanks within the list are 
ignored. This command may appear within the comnand stream in any 
location that is valid for the OPTION command. The REPORT command must 
fit in 80 characters or separate comnands can be given. 

AED does not have common reports or I/O statement reports. AED 
has no I/O statements and only blank common. The blank common is saved 
on the interface library. 

Normally the OPTION command is used. The REPORT command is only 
used to restrict reports. If the same report is requested via an OPTION 
and a REPORT command, the report will not be duplicated. 

3. 6 FOR MODULES 

AVFS will normally analyze all modules. In AED, each module is 
individually analyzed via a separate comnand. In FORTRAN, a data file 
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may contain several modules which are not all to* be analyzed. The FOR 
MODULES command allows the selection of individual FORTRAN modules. 
This command has the form 

FOR MODULES =* (<name l>,<name 2>, ... ). 

where <name 1> and <name 2> are FORTRAN names for modules which have 
been input to AVFS. Main programs ttfiich do not have a program card are 
given the name MAIN. Only one FOR MODULES command per AVFS run is 
allowed . 
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4 


OPTION DESCRIPTIONS 


This section contains descriptions of each option which may be 
selected by the user to instruct AVFS as to whifch type of processing to 
perform on the modules being input. An example of each type of report 
generated by an option follows each description. Table 4. 1 shows the 
AVFS options and suggested uses for each. 

4. 1 LIST 

The LIST option produces a source listing which shows the state- 
ment line number and the automatically indented source code. All refer- 
ences to statements in reports developed by AVFS are keyed to statement 
line numbers and module name. 

The indented listing clearly indicates the control structures and 
makes the program much more readable, not only to the original pro- 
grammer, but especially to someone unfamiliar with the code who is 
trying to understand it. The indented source listing on the output file 
is the sole report from the LIST option. Figure 4.1 illustrates a 
sample listing for a FORTRAN program and for an AED program. 

Some of the other options also provide listings in a different 
format. Examples of those listings are presented in the section 

describing those options. 

FORTRAN Command Report 

OPTION=LIST or FORTRAN Listing (Fig. 4.1a) 

@XQT,L GRC*AVFS .AVFS 

See Appendix C-8 for complete JCL example 

AED Command Report 

@XQT GRC *LI ST • LI ST AED Listing (Fig. 4.1b) 

See Appendix C-ll for complete JCL example 
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TABLE 4.1 

AVFS PROCESSING OPTIONS WITH SUGGESTED USES FOR EACH OPTION 


Options 


Suggested Uses 

LIST 

STATIC 

DOCUMENT 

SUMMARY 

UNITS 

INPUT/OUTPUT 

ASSERT 

INSTRUMENT 

REACHING SET 

VCG 

Software 

Documentation 

X 


X 

X 

X 

X 

X 



X 

Maintenance 

X 

X 

X 

X 

X 

X 

X 

X 


X 

Implementation 

X 

X 

X 

X 

X 

X 

X 

X 


X 

Obtain Interface 
Data 


X 

X 

X 







Trace Ranges 
of Variables 






X 





Check Variables 





X 


X 



X 

Execution Test 






X 

X 

X 

X 


Incomplete Test 
Coverage 






X 


X 

X 


System Test 
Information 

X 


X 

X 

X 


X 




Single Module 
Information 

X 

X 

X 

X 

X 


X 



X 

Code Changes 

X 

X 

X 

X 

X 


X 



X 

Unknown behavior 


X 

X 


X 

X 

X 

X 


X 

Integration 


X 

X 


X 

X 


X 



Acceptance 


X 

X 

X 

X 


X 

X 


X 

Ultnens lonal 
Ana 1 ys Is 

X 




X 






Symbol Ic 
Execution 










X 

Formal 

Verif (cation 







X 



X 
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STATEMENT LISTING SUBROUTINE EXAW*L ( INFO# LENGTH) 


STMT 

NEST 

LINE 

SOURCE... 

» • .SOURCE TAB 

1 


1 


SUBROUTINE EXAMPL < INFO •LENGTH) 




2 

C 


EXAMPL2 



3 

c 

ILLUSTRATION OF DMA TRAN SYNTAX 

EXAMPL3 



4 

c 


EXAMPL4 

2 


5 


IF (INFO. LE. 10 .AND. LENGTH . QT . 0 ) THEN 

EXAMPL5 

3 

1 

6 


CALL CALLER ( INFO ) 

EXAHPL6 

4 


7 


ELSE 

EXAMPL7 

5 

1 

a 


LENGTH-50 

EXAMPL8 

6 


? 


END IF 

EXAMFL9 

7 


10 


CASE OF CINFO+6) 

EXAMPL10 

a 


n 


CASE (14) 

EXAfTLll 

9 

1 

12 


LENGTH-LENGTH-INFO 

EXAMFL12 

10 


13 


CASE (17) 

EXAMPL13 

11 

1 

14 


DO UHILE (INFO. LT. 20) 

EXAMPL14 

12 

2 

15 


DO UNTIL < LENGTH. LE. INFO) 

EXAMPL15 

13 

3 

16 


. . . INVOKE (CONFUTE LENGTH) 

EXAMPL16 

14 

3 

17 


. . . IF (LENGTH. G£. 30) THEN 

EXAMPL17 

15 

4 

18 


. . . . INVOKE (PRINT-RESULTS) 

EXAMPL18 

16 

3 

19 


. . . END IF 

EXAMFL19 

17 

2 

20 


. . END UNTIL 

EXAMPL20 

18 

2 

21 


, . INFO— INFQ+1 

EXAMPL21 

19 

1 

22 


END UHILE 

EXAMPL22 

20 


23 


CASE ELSE 

EXAMPL23 

21 

1 

24 


. DO UHILE (LENGTH. GT.O) 

EXAMPL24 

22 

2 

25 


. . INVOKE (COMPUTE LENGTH) 

EXAMPL25 

23 

1 

26 


END UHILE 

EXAMPL26 

24 


27 


END CASE 

EXAMPL27 

25 


29 


BLOCK (PRINT-RESULTS) 

EXANPL29 

26 

1 

29 


. URITE (6*1) INFO .LENGTH 

EXAMPL29 

27 

1 

30 


1 . FORMAT U0X.I5,20X,I5) 

EXAMPL30 

28 


31 


END BLOCK 

EXAWJl 

29 


32 


BLOCK (COMPUTE LENGTH) 

EXAMPL32 

30 

1 

33 


. LENGTH - LENGTH -10 

EXAMFL33 

31 


34 


END BLOCK 

EXAMPL34 

32 


35 


RETURN 

EXAMFL35 

33 


36 


END 

EXAMPL36 


This report contains 
source line numbers , 


the indented module listing with statement numbers, 
and nesting levels. 


Figure 4.1a. FORTRAN Listing 
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14 

DEFINE PROCEDURE B.LONG 

.COM TOBE 

15 



16 

COMMENT ITERATION RATE 

- 10 / SEC ; 

17 

BEGIN 


18 

NORM. ACC - VOTER (NORM. ACC • PTR) ... VOTE NORMAL ACCELERATION ; 

19 

NORM. ACC .LP - DLIMIT(NORM.ACC.LP+(NORM.ACC-NORM.ACC.LP)*.5D-2 ! 

20 

.442550D-1) 

... NORM. ACC. LP IS SUBTRACTED FROM 

21 


NORM. ACC BY OTHER PROCEDURES FOR 

22 


SEC WASHOUT ON NORM. ACC ; 

23 

TAS - TAS.MA 

... BUFFER TAS FOR GAIN PROGRAMERS ; 

24 

KVTAS - 

... GAIN PROGRAMER // 

25 

IF TAS < .146484 

... 150 KTS // 

26 

THEN .5 


27 

ELSE IF TAS < 

.341797 ... 350 KTS // 

28 

THEN 

.75-TAS/. 585936 

29 

ELSE 

.166667; 


This report contains the indented module listing with statement 
line numbers. 


Figure 4.1b. AED Listing 
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4.2 STATIC 

The static analysis available in AVFS is designed to uncover 
inconsistencies in the use of variables and inconsistencies in the 
structure of a program. When an inconsistency is found, it indicates 
the existence of an error or the possibility of an error. 

Static analysis is divided into single module analysis, units 
analysis, and interface analysis. Assertions are not required for 
static analysis, but a more comprehensive analysis is possible when 
assertions have been added to the user's source program. A complete 
static analysis checks for the following types of errors: 

Set and Use Checking 

Variables used before being set to a value or set and not 
used. 

Loop Checking 

Uninitialized loop variables. 

Type Checking 

Possible misuse of variables in assignments. 

Graph Checking 

Unreachable statements. 

Interface Checking 

Checking of actual invocations against formal declarations; 
checking for consistency in number of parameters and type. 

Input/Output Checking 

Check that asserted use of a variable is the same as its 
actual value 
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UNITS 


Units assertions can be inserted into a program so that consis- 
tency checks can be made on the use of units. Each variable for which 
units are to be specified has its units declared in the form: 

COMMENT UNITS <variable> - <units expression^ 

For example, to state that the variable named SPEED has the units of 
FEET/ SEC, write 

COMMENT UNITS SPEED « FEET/SEC; 

To state that the variable named DIST has the units of FEET, write 
COMMENT DIST - FEET; 

The units analyzer will check that operations on variables which have 
specified units is done in a consistent manner. That is, if an assign- 
ment was made such as 

SPEED « DIST; 

the units analyzer would report on a units error stating that 
FEET - FEET/ SEC; 
was attempted. 

Units are combined symbolically across multiplication and division 
to form new units. Checks are made across addition, subtraction and 
assignment operations to ensure units consistency. 

After the analysis is complete, the units for each variable is 
listed in the units table. 

The example in Fig. 4.4 shows units specified for speed, distance, 
time, work and force. The first assignment to speed specifies that it 
will have the units of SAMPLE. Since SAMPLE does not have its units 

specified, no checking is done. The second assignment statement shows 
what is printed when there is an error detected in the units. The units 
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of DIST*TIME are FEET*SEC which is printed on the right of the equals 
sign* The units of SPEED are FEET/SEC which is printed on the left hand 
side of the equals sign. Since the units on the left do not match the 
units on the right, an error is declared* The other two assignments 
have the correct units* 

Input/Output 

Input/Output assertions are used in a static analysis to check for 
consistency between the intended use of a variable and the actual use of 
a variable. 

Variables which provide input data to a module should be asserted 
with an input assertion. 

An input assertion has the form 

COMMENT INPUT <type> <variable>; 

For example, the assertion 

COMMENT INPUT REAL HEIGHT; 

states that the vraiable named HEIGHT is an input to the module. 

Variables which provide output data from a module should be 
asserted with an output assertion. An output assertion has the form 

COMMENT OUTPUT <type> <variable>. 

Variables which are used both as input and output are asserted in 
both assertions. 
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FORTRAN Command 


Report 

OPTION ^STATIC, LI ST. Static Analysis (Fig. 4.2) 

or @XQT, LS GRC*AVFS .AVFS 

See Appendix C-6 for complete JCL example 


AED Command Report 

@XQT GRC*SYMBOL. SYMBOL Static Analysis (Fig. 4.3) 

See Appendix C-12 for complete JCL example 


AED Command Report 

@XQT GRC*UNITS. UNITS Units Analysis (Fig. 4.4) 

See Appendix C-13 for complete JCL example 


AED Command Report 

@XQT GRC*INTER. INTER Interface Analysis (Fig. 4.5) 

See Appendix C-14 for complete JCL example 
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STATIC ANALYSIS 
STMT NEST LINE SOURCE... 


SUBROUTINE CIRCLE < AREA > 


...SOURCE TAB 


13 


15 


SUBROUTINE CIRCLE < AREA ) 

INTEGER AREA 

DATA PI / 3.1416 / 

INPUT </R/ RADIUS ) 

RADIUS - DIAHTR / 2 


VARIABLE DIAHTR 
5 


SET/USE ERROR 
USED BUT >«VER SET 


REFER TO STATEMENT CS)- 


AREA - PI * RADIUS«2 


* MODE UARNING 

- LETT HAND SIDE HAS NODE INTEGER RIGHT HAND SIDE MODE REAL 


IF ( AREA .GT. 50 > THEN 
. CALL PRINT ( AREA ) 


-PARAMETER 1 OF PRINT 


MODE UARNING 

ACTUAL PARAMETER HAS MODE INTEGER 
FORMAL PARAMETER HAS MODE REAL 


PRINT 


CALL ERROR 

CALLED UITH 1 ACTUALLY HAS 2 ARGUMENTS 


9 

10 

END IF 

10 

11 

OUTPUT </R/ AREA ) 

11 

13 

RETURN 

12 

14 

CALL STACK ( RADIUS 


AREA ) 


GRAPH UARNING 

STATEMENT 12 IS UNREACHABLE OR IS IN AN INFINITE LOOP 


END 


STATIC ANALYSIS SUMMARY 


ERRORS UARNINGS 


GRAPH CHECKING 0 1 

CALL CHECKING 1 0 

MODE CHECKING 0 2 

SET/USE CHECKING 1 0 

CALL CHECKING UAS NOT PERFORMED FOR THE FOLLOWING UNKNOWN EXTERNALS 
STACK 


The FORTRAN Static Analysis Summary contains the warning and error 
messages interspersed in the code. Unknown subprograms are listed at 
the bottom of the report. A tabulation of errors and warnings is listed 
at the bottom. The STMT column lists the line numbers for each input 
source statement. The NEST column lists the nesting level for each 
statement in a control structure. The LINE column lists the line 
numbers for each generated source statement. Since input and output 
assertions require two generated lines, the LINE column differs from the 
STMT column. 


Figure 4.2 Static Analysis - FORTRAN 
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FIRST 

TOTAL 

LAST 

ASSERTED ACTUAL 

NAME 

CLASS 

MODE 

STMT. 

USES 

STMT. 

USE USE 

A 

PARAMETER 

REAL 

1 

3 

6 

INPUT 

N 

PARAMETER 

INTEGER 

i 

4 

9 

BOTH 

ANS 

PARAMETER 

REAL 

1 

3 

9 

OUTPUT 

1 

LOCAL 

INTEGER 

2 

5 

7 




m 




SET/USE ERROR 



m 

VARIABLE I 



USED BEFORE BEING 
ASSIGNED A VALUE 

0 

LOCAL 

INTEGER 

2 

z 

4 


SUM 

LOCAL 

REAL 

3 

4 

9 




m 




SET/USE ERROR 



• 

VARIABLE SUM 



USED BEFORE BEING 
ASSIGNED A VALUE 


Set use checking and input/ output analysis is reported after the 
listing is presented for AED. 


Figure 4.3. Static Analysis - AED 
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59 


60 COMMENT UNITS SPEED - FEET/SEC; 

61 COMMENT UNITS DIST - FEET; 

62 COMMENT UNITS TIME - SEC; 

63 COMMENT UNITS WORK - POUND *FEET ; 

64 COMMENT UNITS FORCE - POUND; 

65 

66 SPEED - SAMPLE; 

67 SPEED - DIST * TIME; 

*****units error***** 
FEET/SEC-FEET*SEC 

68 DIST - SPEED * TIME; 

69 WORK - FORCE * DIST; 

70 

71 


UNITS TABLE 


SPEED 

FEET/SEC 

DIST 

FEET 

TIME 

SEC 

WORK 

POUND*FEET 

FORCE 

POUND 


Inconsistent units are reported during units analysis. 


Figure 4.4. Units Analysis - AED 



INTERFACE REPORT 


MODULE 


TYPE OF CHANGE 


A. FORE. EXEC 


NEW MODULE 


A.BAK.EXEC 


UPDATED MODULE 

**** PARAMETER LENGTH CHANGE 


A. YAW. END 


UPDATED MODULE 

**** COMMON TYPE CHANGE 


INTERFACE ANALYSIS 

MODULE TYPE OF ERROR 


A. MAKE. IT PARAMETER LENGTHS INCONSISTENT 

ACTUAL - 2 PARAMETERS 
A.BAK.EXEC (C,D) 

FORMAL - 3 PARAMETERS 
A.BAK.EXEC (A,B,C) 


1 INTERFACE ERRORS 


Checking between modules on a library is performed to produce an 
interface analysis along with changes to the interface. 


Figure 4.5. Interface Analysis - AED 
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4.3 DOCUMENT 

The DOCUMENT option generates a set of reports for individual 
modules and multiple modules. Figures 4.6 - 4.16 contain examples and a 
description of each report. 

The set of reports are useful for maintenance and testing. 

Together with the execution coverage reports, they help to identify 
which modules require retesting when changes are made to the source 

code. The cross reference reports are particularly useful in finding 
where variables are set in order to alter test cases, and also where a 
variable is being used that is affected by a change in a module. The 
flowgraph or picture report is useful for breaking up large FORTRAN 

programs. 

AED programs have no I/O statements and only one common block. 
There is no AED I/O Statements Report or commons matrices. The AED 

commons and externals cross references are combined in a single global 
cross reference. 



FORTRAN 

AED 

Report 

Command 

Command 

Symbols 

OPTION=DOCUMENT 
(Fig. 4.6a) 

GRC*SYMBOL. SYMBOL 
(Fig. 4.6b) 
Appendix C-12 

Cross Reference 

OPT ION “DOCUMENT 
(Fig. 4.7a) 

GRC*CR0SS. CROSS 
(Fig. 4.7b) 
Appendix C-15 

Invocation Space 

OPTION “DOCUMENT 
(Fig. 4.8a) 

GRC*IN VO KE. INVOKE 
(Fig. 4.8b) 
Appendix C-16 

Invocation Summary 

OPTION “DOCUMENT 
(Fig. 4.9a) 

GRC*DEPEND. DEPEND 
(Fig. 4.9b) 
Appendix C-17 

Invocation Bands 

OPTION “DOCUMENT 
(Fig. 4.10a) 

GRC*TREE. TREE 
(Fig. 4.10b) 
Appendix C-18 
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Common Matrices 

OPTION-DOCUMENT 
(Fig. 4.11) 


I/O Statements 

OPTION -DOCUMENT 
(Fig. 4.12) 


Commons Cross 

OPTION-DOCUMENT 

GRC*GL0BAL. GLOBAL 

Reference 

(Fig. 4.13) 

(Fig. 4.14b) 
Appendix C-19 

Externals Cross 

OPTION-DOCUMENT 

GRC*GLOBAL. GLOBAL 

Reference 

(Fig. 4.14a) 

(Fig. 4.14b) 
Appendix C-19 

Flowgraph 

OPTION -DOCUMENT 

GRC .FLOW .FLOW 


REPORT-PICTURE 



(Fig. 4.15) 

(Fig. 4.16) 


The FORTRAN command 


OPTION =DOCUMENT 

maybe replaced with the UNI VAC command 

@XQT,D GRC * AVFS . A VF S • 

The complete JCL for the document command is shown on page C-9. This 

command will produce the nine reports shown in Figs. 4.6-4.14. The 
flowgraph report (Fig. 4.15) will also be generated if the conmand 

R£PORT=PICTURE 

is added after the OPTION command or the XQT command. 

The corresponding AED commands are listed beside the FORTRAN 
commands. In most cases a single AED command produces a single report 
which corresponds to a FORTRAN report. The exceptions are: the command 

which causes AED invocation analysis to produce two reports (Figs. 4.8b, 
4.9b) and the command which presents a multiple module cross reference 
to incorporate two reports (Fig. 4. 14b) 
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SYMBOLS SUBROUTINE SDBASA ( MODULE. I STMT. IRE7RN ) 


NAME 

SCOPE 

TYPE 

MODE 

USE OTHER INFORMATION. . . 

KXFAR 

KDELMS 

VARIABLE 

INTEGER 

USED 

KXPARM 

RFTCOM 

VARIABLE 

INTEGER 

USED 

KXTPLS 

RPTCOM 

VARIABLE 

INTEGER 

USED 

LIST 

MTHSTO 

ARRAr 

INTEGER 

SET/USED 

MARGS 

MDB 

VARIABLE 

INI EGER 

SET 

MBLOKS 

MDR 

VARIABLE 

INTEGER 

EQUIV 

MBRCHN 

MTHTYP 

VARIABLE 

INTEGER 

USED 

MCALL 

MTHTYP 

VARIABLE 

INTEGER 

USED 

MCIQ 

MTHTYP 

VARIABLE 

INTEGER 

USED 

MCMMNS 

MDB 

VARIABLE 

INTEGER 

SET/USED 

MDUM26 

(LOCAL) 

VARIABLE 

INTEGER 

EOUIV 

MEN TR 

MTHTYP 

VARIABLE 

INTEGER 

USED 

MENTRS 

MDB 

VARIABLE 

INTEGER 

SET/USED 

MENTR2 

MTHTYP 

VARIABLE 

INTEGER- 

USED 

MEGLS 

(LOCAL) 

VARIABLE 

INTEGER 

SET/USED 

MEOUVS 

MDB 

VARIABLE 

INTEGER 

SET/USED 

MEXEC 

MTHTYP 

VARIABLE 

INTEGER 

USED 

MEXIT 

MTHTYP 

VARIABLE 

INTEGER 

USED 

MGOTO 

MTHTYP 

VARIABLE 

INTEGER 

USED 

MIF 

MTHTYP 

VARIABLE 

INTEGER 

USED 

MJUNCT 

MTHTYP 

VARIABLE 

INTEGER 

USED 

MMODE 

MDB 

VARIABLE 

INTEGER 

SET/USED 

MNAME 

MDB 

VARIABLE 

INTEGER 

ECUIV 

MNONX 

MTHTYP 

VARIABLE 

INTEGER 

USED 

MODULE 

PARAMETER 

VARIABLE 

INTEGER 


MF-RSET 

MTHTYP 

VARIABLE 

INTEGER 

USED 

MREAD 

MTHTYP 

VARIABLE 

INTEGER 

USED 

MREADS 

MDB 

VARIABLE 

INTEGER 

SET/USED 

HTYF'E 

MDB 

VARIABLE 

INTEGER 

SET 

MURITS 

MDB 

VARIABLE 

INTEGER 

SET/USED 

NONEXS 

(LOCAL) 

ARRAY 

INTEGER 

SET/USED 

NUMEXS 

(LOCAL) 

VARIABLE 

INTEGER 

SET/USED 

NUMNGN 

(LOCAL) 

VARIABLE 

INTEGER 

SET/USED 


THE FOU.OUING LOCAL VARIABLES UERE DEFINED BUT NOT USED... 
TOKADO 


THE FCLLOUING NONLOCAL VARIABLES ARE SET... 

IRETRN MTYPE MMODE MCMMNS hENTRS MARGS MEOUVS MREADS MURITS ISTYF^E ISCODE 
ISINFO LIST 


This report is generated for each module analyzed during an AVFS 
run. The symbols are ordered alphabetically, and symbols which are only 
defined and never referenced are not included. Symbols which have the 
scope (LOCAL) are known only within the module being reported on. 
Symbols with the scope parameter are formal parameters for the module. 
All other scope classifications indicate the name of the common block 
the common variables are defined in. Each symbol is either of type 
variable or array, and of mode integer, real, logical, character, 
complex, or double precision. The use column provides a summary of how 
the symbol is used in the module. Local symbols which were defined but 
not referenced and all non-local variables (parameters and common 
variables) which are set within the module are noted at the end of the 
report. 


Figure 4.6a. FORTRAN Symbols Report 
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SET/USE ANALYSIS AND PARAMETER REPORT MODULE VOTER 





1ST 

LAST 

TOTL 

ASSERTED 

ACTUAL 

NAME 

SCOPE 

CLASS 

STMT 

STMT 

USES 

USE 

USE 

K3 

LOCAL 

VARIABLE 

74 

74 

1 



K4 

LOCAL 

VARIABLE 

74 

74 

1 



K5 

LOCAL 

VARIABLE 

74 

74 

1 



K6 

LOCAL 

VARIABLE 

74 

74 

1 



K7 

LOCAL 

VARIABLE 

74 

74 

1 



K8 

LOCAL 

VARIABLE 

74 

74 

1 



K9 

LOCAL 

VARIABLE 

74 

74 

1 



LIMIT 

EXTERNAL 

PROCEDURE 

20 

23 

4 



LX1 

LOCAL 

VARIABLE 

17 

18 

2 



LX2 

LOCAL 

VARIABLE 

17 

18 

2 



LX3 

LOCAL 

VARIABLE 

17 

17 

1 



LX4 

LOCAL 

VARIABLE 

17 

17 

1 



MONDAY 

EXTERNAL 

PROCEDURE 

104 

104 

1 



MPS1 

- 

- 

47 

65 

4 



MPS2 

- 

- 

51 

68 

4 



MPS3 

- 

- 

55 

69 

5 



NEWPROC 

EXTERNAL 

PROCEDURE 

85 

117 

3 



NEWPROC2 

- 

- 

119 

119 

1 



- 


SET/USE ERROR 




VARIABLE 

NEWPROC2 

USED 

BEFORE BEING ASSIGNED A VALUE 

NOCALLFROM 

EXTERNAL 

PROCEDURE 

88 

94 

2 



OWN.PTR 

- 

- 

15 

62 

11 



PARI 

PARAMETER 

VARIABLE 

5 

26 

4 

INPUT 

INPUT 

PAR2 

PARAMETER 

VARIABLE 

5 

28 

5 

OUTPUT 

OUTPUT 

PAR3 

PARAMETER 

VARIABLE 

5 

28 

3 

NONE 

OUTPUT 

PROC1 

EXTERNAL 

PROCEDURE 

10 

46 

2 



PROC2 

EXTERNAL 

PROCEDURE 

13 

46 

2 



PROCCALLO 

- 

- 

37 

37 

1 



P ROC CALL 1 

EXTERNAL 

PROCEDURE 

39 

115 

10 






PARAMETER ERROR 

_ 

- PROCEDURE 

PROCCALL1 

MULTIPLE USE OF SAME ACTUAL 

- 

- 


PARAMETER IN LINE 39 

- 


_ 


PARAMETER ERROR 

- 

- PROCEDURE 

PROCCALL1 

CONSTANT USED AS ACTUAL 

- 

- 


PARAMETER IN LINE 40 

- 




PARAMETER ERROR 

_ 

-PROCEDURE 

PROCCALL1 

FUNCTION/PROCEDURE USED AS ACTUAL 

- 

- 


PARAMETER IN LINE 41 

- 


Figure 4.6b. AED Symbols Report 
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Figure 4.6(b) continued 


This report is generated for each module analyzed by AVFS. The 
symbols are ordered alphabetically. Symbols which have the scope LOCAL 
are known only within the module being reported on. Other symbols with 
the EXTERNAL classification or COMMON classification are known outside 
the module. Each symbol is classified as to its class: variable, 
array, procedure, and to its type. The use column provides a summary of 
how the symbol is used in the module. 
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CROSS REFERENCE 


SUBROUTINE SDBASA < MODULE * ISTMT , IRETRN ) 


NAME SCOPE MODULE USED/SET /EQUIVALENCES ( * INDICATES SET ) 


ADDEPT 

EXTERNAL 

SDBASA 

65 

84 

250 










CALLED 

(LOCAL) 

S DBAS A 

24* 

274 

275* 










ERROR 

EXTERNAL 

SDBASA 

151 












I 

(LOCAL) 

SDBASA 

48* 

4? 

50 

51* 

51 

75* 

76 

77 

78* 

78 

120* 

121 




145 

146 

161* 

162 

171* 

172 

172 

173* 

173 

175 

177 

191* 




227 

228 

342* 

343 

343 

344* 

344 

346 

353* 

354 

354 

355* 

IAGT 

ANSI 

SDBASA 

14? 












IBAPAR 

EXTERNAL 

SDBASA 

115 

170 

210 










ICGT 

ANSI 

SDBASA 

147 












ICOMAS 

(LOCAL) 

SDBASA 

119* 

123* 

123 

127 









IDUM 

(LOCAL) 

SDBASA 

37 

54 

139 

169 









IDX 

(LOCAL) 

SDBASA 

32* 

33 

33 

33 

34* 

34 

36 

41 

41 

43 

49 

36 




76 

80* 

80 

82* 

82 

84 







I END 

ANSI 

SDBASA 

307 












IENT 

ANSI 

SDBASA 

246 

316 











I EXECS 

(LOCAL) 

SDBASA 

307* 

308* 

309* 

310* 

311* 

312* 

313* 

314* 

315* 

316* 

317* 

318* 




327* 

328* 

329* 

330* 

331* 

332* 

333* 

334* 

335* 

336* 

337* 

354 

I FT 

ANSI 

SDBASA 

113 

308 











IF2 

ANSI 

SDBASA 

128 












IF3 

ANSI 

SDBASA 

131 












IGT 

ANSI 

SDBASA 

136 

311 











IGTTOK 

EXTERNAL 

SDBASA 

137 












IMDB 

(LOCAL) 

SDBASA 

10E 












IPAR 

(LOCAL) 

SDBASA 

115* 

116 

117 

120 

170* 

172 

175 

* 

o 

CD 

182 

182 

184 


I RE ADC 

FTNEXT 

SDBASA 

235 












IRET 

ANSI 

SDBASA 

188 

315 











IRETRN 

PARAMETE 

SDBASA 

25* 

269* 











ISCLAS 

EXTERNAL 

SDBASA 

138 












ISCODE 

SDK 

SDBASA 

29* 

67* 

89* 

97* 

112* 

114* 

118* 

140* 

155* 

159* 

167** 

176* 

I SDB 

(LOCAL) 

SDBASA 

16E 












ISEXEC 

(LOCAL) 

SDBASA 

111 

358* 

360* 










ISINFO 

SDB 

SDBASA 

31* 

129* 

132* 

139* 

169* 

199* 

204* 

210* 

212 

215 

228* 

249* 

ISLABL 

SDB 

SDBASA 

16E 












ISLONG 

SDB 

SDBASA 

33 

36 

37 

41 

59 

70 

73 

115 

116 

121 

139 

142 




192 

206* 

206 

210 

224 

ony 







ISNONX 

(LOCAL) 

SDBASA 

88 

347* 

349* 










ISPTR 

SDB 

SDBASA 

117* 

145* 

177* 

184* 

185 

216* 

234 

240 





ISTMT 

PARAMETE 

SDBASA 

65 

84 

103 

250 









ISTOP 

ANSI 

SDBASA 

188 

190 

318 










ISTYPE 

SDB 

SDBASA 

27 

27 

27 

42* 

5? 

64 

74* 

90 

93 

96 

99 

100* 




1 66 

188 

188 

190 

198 

203 

208 

208 

208 

208 

208 

208 




252 

255 

255 

255 

343 

354 







ITEM 

(LOCAL) 

SDBASA 

137* 

138 











IVMOBE 

EXTERNAL 

SDBASA 

54 












IURTEC 

FTNEXT 

SDBASA 

241 












IXABNL 

FTNEXT 

SDBASA 

302 












IXASS 

ANSI 

SDBASA 

252 

317 












This report provides a symbol cross reference for each module 
analyzed during an AVFS run* All local symbols, external symbols, and 
common symbols referenced in the module are included* Symbol names are 
ordered alphabetically in the first column* The scope column indicates 
symbols known only within this module (LOCAL), external symbols, and 
symbols which are defined in common blocks included in the module (all 
others)* Statements (AVFS statement numbers) which use a symbol are 
followed by a blank, statements which set a symbol are followed by a 
and equivalence statements containing the symbol are followed by an 

'E'* 

Figure 4.7a* FORTRAN Cross Reference Report 
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CROSS REFERENCE 


MODULE VOTER 


NAME 

D /SET (S) /DEFINED 

SCOPE 

(D) 

CLASS 

TYPE 

USED OR 

REFERENCE 

K6 

LOCAL 

VARIABLE 

INTEGER 

74D 



K7 

LOCAL 

VARIABLE 

INTEGER 

74D 



K8 

LOCAL 

VARIABLE 

INTEGER 

74D 



K9 

LOCAL 

VARIABLE 

INTEGER 

74D 



LIMIT 

EXTERNAL 

PROCEDURE 

REAL 

20 

21 

22 

23 







LX1 

LOCAL 

VARIABLE 

LABEL 

17D 

18D 


LX2 

LOCAL 

VARIABLE 

LABEL 

17D 

18D 


LX3 

LOCAL 

VARIABLE 

LABEL 

17D 



LX4 

LOCAL 

VARIABLE 

LABEL 

17D 



MONDAY 

EXTERNAL 

PROCEDURE 

- 

104D 



MPS1 

- 

- 

- 

47S 

63 

64 

MPS2 

- 

- 

- 

51S 

63 

67 

MPS3 

- 

- 

- 

55S 

64 

66 

NEWPROC 

EXTERNAL 

PROCEDURE 


85 

97 

117D 

NEWPROC2 

- 

- 

- 

119 



NOCALLFROM 

EXTERNAL 

PROCEDURE 

- 

88D 

94 


OWN.PTR 

- 

- 

- 

15S 

20 

20 





35 

62 


PARI 

PARAMETER 

VARIABLE 

INTEGER 

5 

6D 

24 

26 







PAR2 

PARAMETER 

VARIABLE 

INTEGER 

5 

6D 

25 

27S 28 







PAR3 

PARAMETER 

VARIABLE 

INTEGER 

5 

6D 

28S 

PROC1 

EXTERNAL 

PROCEDURE 

- 

10D 

46 


PR0C2 

EXTERNAL 

PROCEDURE 

INTEGER 

13D 

46 


PROCCALLO 

- 

- 

- 

37 



PROCCALL1 

EXTERNAL 

PROCEDURE 

- 

39 

40 

41 





115 



P ROC CALL 2 

EXTERNAL 

PROCEDURE 

- 

46 

110 

113D 

PROCCALL3 

- 

- 

- 

45 



PTR 

PARAMETER 

VARIABLE 

INPUT. POINTE 

5 

6D 

15 

R1 

EXTERNAL 

VARIABLE 

INTEGER 

11D 

12 


ROBERT 

LOCAL 

SWITCH 

LABEL 

18D 



ROBERT1 

EXTERNAL 

PROCEDURE 

- 

8 2D 

98 


ROBERT2 

EXTERNAL 

PROCEDURE 

- 

100D 



ROBERTG 

- 

- 

- 

38 



SIGNAL 

- 

- 

- 

20 

21 

22 

SIGNAL. MA 

- 

- 

- 

20S 

48 

49 

SIGNAL. MB 




21S 

48 

50 

SIGNAL. OA 

- 

- 

- 

22S 

52 

54 

SIGNAL. OB 




23S 

56 

58 

SYNI 

LOCAL 

SYNONYM 

- 

16D 



SYN1A 

LOCAL 

SYNONYM 

- 

16D 

36 


SYN1B 

LOCAL 

SYNONYM 

- 

16D 




Figure 4.7b. AED Cross Reference 
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Figure 4.7(b) continued 


This report provides a symbol cross reference for each module 
analyzed by AVFS. All local symbols, external symbols, common symbols, 
and parameters referenced in the module are included. Symbol names are 
ordered alphabetically in the first column. The scope column indicates 
symbols known only in this module (LOCAL) , external symbols (EXTERNAL) , 
and common symbols (COMMON), and parameters (PARAMETER). Statements are 
identified by line number as to whether the symbol was defined, set, or 
used in a particular line. 
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INVOCATION SPACE 


SUBROUTINE CRDOUT < CARD * KEY ) 


INVOCATIONS FROM UITHIN THIS MODULE 


HODULE 

A1IO 






STMT = 

117 

CALL 

A1IQ ( 

2 

f I OUT f LINEX , 

STMT = 

173 

CALL 

A1I0 ( 

2 

• ICUT • HEADX , 

STMT = 

174 

CALL 

A1IQ < 

2 

, IOUT , SKIP , : 

MODULE 

BUFOUT 






STMT = 

132 

CALL 

BUFOUT 




STMT = 

148 

CALL 

BUFOUT 




STMT * 

153 

CALL 

BUFOUT 




MODULE 

CVD 






STMT = 

50 

CALL 

CVD < NCARD f 

NCARD5 ) 

STMT = 

67 

CALL 

CVD ( NEST , 1 

NESTS ) 

STMT = 

172 

CALL 

CVD < 1 

NPAGE f 

HEADX < 111 

MODULE 

IABS 






STMT » 

48 

IABS 

< INDENT 

> 


MODULE 

ICMTST 






STMT « 

57 

ICMTST < CARD 

< 2 

> ) 

STMT =• 

88 

ICMTST < CARD 

( I 

) ) 

STMT =* 

121 

ICMTST < CARD 

< 2 

) > 

INVOCATIONS TO THIS 

MODULE FROM UITHIN ! 

LIBRARY 

MODULE 

CMTOPT 






STMT « 

112 

CALL 

CRDQUT 

( 

CARD 

* ICOM ) 

MODULE 

IFTRA 






STMT = 

69 

CALL 

CRDOUT 

< 

CARD 

* 4 ) 

STMT = 

80 

CALL 

CRDQUT 

( 

CARD 

f 4 ) 

STMT « 

88 

CALL 

CRDOUT 

( 

CARD 

, 4 ) 

STMT » 

97 

CALL 

CRDOUT 

( 

CARD 

r 1 ) 

STMT ■ 

108 

CALL 

CRDOUT 

< 

CARD 

. 1 ) 

STMT * 

176 

CALL 

CRDOUT 

< 

CARD 

, 1 ) 

STMT - 

181 

CALL 

CRDOUT 

< 

0 « * 

- 101 ) 

STMT ■ 

188 

CALL 

CRDOUT 

< 

CARD 

, 1 ) 

STMT * 

233 

CALL 

CRDOUT 

< 

CARD 

• 1 ) 

STMT = 

238 

CALL 

CRDOUT 

< 

CARD 

f 0 ) 

STMT = 

248 

CALL 

CRDOUT 

( 

CARD 

• 0 ) 


LLINEX ) 
120 ) 

LO ) 


This module report shows all invocations, along with the AVFS 
statement numbers, to and from the specified module. It is useful in 
examining actual parameter usage. The text printed is reformatted and 
may contain more or fewer blanks than the original text line. A summary 
of this report is provided by the externals cross reference report. 
This report is produced for modules analyzed during an AVFS run. 


Figure 4.8a. FORTRAN Invocation Space Report 
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INVOCATIONS TO THIS MODULE 


PROCEDURE NEWPROC 


STMT 

97 

IP ROC 

STMT 

85 

ROBERT 1 

PROCEDURE PROCCALL2 
STMT 110 

PROCCALL1 

STMT 

46 

VOTER 

PROCEDURE PROCCALL1 
STMT 115 

PROCCALL2 

STMT 

111 

PROCCALL1 

STMT 

106 

MONDAY 

STMT 

44 

VOTER 

STMT 

43 

VOTER 


INVOCATIONS REPORT MODULE VOTER 

PACE 1 


INVOCATIONS FROM WITHIN THIS MODULE 


PROCEDURE NEWPROC 

STMT 119 NEWPROC 2; 

PROCEDURE PROCCALL2 

STMT 115 PR0CCALL1 ; 

PROCEDURE PROCCALL1 

STMT 111 FROCCALL1; 

STMT 110 PROCCALL2; 

PROCEDURE MONDAY 

STMT 106 PROCCALL1; 

PROCEDURE ROBERT 2 

-CONTAINS NO PROCEDURE CALLS 

This module report shows all invocations, along with the AVFS 
statement numbers, to and from the specified module. It is useful in 
examining actual parameter usage. 


Figure 4.8b. AED Invocation Space Report 
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INVOCATION SUMMARY 


ENTRY 


LISTS OF CALLS 


PUTLST UHICH IS DEFINED IN GETBLK 
IS CALLED BY - -NONE- 

AND CALLS - GETFRG MAKFRG XMIT 

PUTURD UHICH IS DEFINED IN GETBLK 

IS CALLED BY - PUTBEF PUTBOT 
AND CALLS - GETFRG MAKFRG XMIT 

XMIT UHICH IS UNDEFINED 

IS CALLED BY - GETBLK NEXT PREV PUTAT PUTBEF PUTBOT 

THE FOLLDUING ENTRIES ARE NOT CALLED 

GETBLK GETLST GETURD ISRTAB NEXT PREV PUTAT 


This report shows the dependencies of the modules on the library 
by listing all modules which call an entry point and all calls from that 
entry point. If an entry is defined as an entry point within a module, 
the name of the module is indicated. This report includes all modules 
and entrys on the restart file. An updated version of the report may be 
obtained by reanalyzing all changed modules and using the EXPAND option. 
The actual statements where invocations to a given entry point occur can 
be found in the externals cross reference report. 


Figure 4.9a. FORTRAN Invocation Summary Report 


49 



MODULE DEPENDENCE REPORT 
PROCEDURE DEPENDENCY 


MODULE VOTER 
PAGE 1 


NEWPROC 

IS INVOKED BY 

RQBERT1 

XPROC 


AND INVOKES 

NEWPROC 2 


PROCCALL2 

IS INVOKED BY 

PR0CCALL1 

VOTER 


AND INVOKES 

PR0CCALL1 


PR0CCALL1 

IS INVOKED BY 

MONDAY 

PROCCALLI 

PR0CCALL2 

VOTER 




AND INVOKES 

PROCCALLI 

PRO C CALL 2 

MONDAY 

IS INVOKED BY 

-NONE 



AND INVOKES 

PROCCALLI 


R0BERT2 

IS INVOKED BY 

-NONE 



AND INVOKES 

-NONE 


XPROC 

IS INVOKED BY 

ROBERT1 



AND INVOKES 

NEWPROC 

NOCALLFROM 

ROBERT 1 

XPR0C1 

XPR0C2 


NOCALLFROM 

IS INVOKED BY 

XPROC 



AND INVOKES 

-NONE 


R0BERT1 

IS INVOKED BY 

XPROC 



AND INVOKES 

NEWPROC 

XPROC 

VOTER 

IS INVOKED BY 

-NONE 



AND INVOKES 

PROCCALLO 

PROCCALLI 

PR0CCALL2 

PR0CCALL3 

ROBERTG 



This report shows the dependencies of the modules on the interface 
library. It lists all modules which invoke a module and all invocations 
in a module. The actual statements where invocations to a given module 
occur can be found in the invocation space report or the global cross 
reference report. 


Figure 4.9b, AED Invocation Summary Report 
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INVOCATION 

BANDS a 



SUBROUTINE 

BLDSDB ( 

MODULE. ISTMT » IACT. 

IASERT ) 




TO LEVEL 2 











LEVEL 

-3 

-4 

-3 

-2 

-1 

0 1 

2 

3 

4 

5 


BLBSDB 

PASTUQ 


ISASGN 

SBBASA 


SDBAST 

SDBIFT 

SB8RUN 

SDBSTR 

TOKADD 


ADDEPT 

ERROR 

IBAPAR 

IGTTOK 

ISCLAS 

IVMODE 

JGET 

NMBARG 

RSTMPL 

XrtIT 


This report shows the selected module within the invocation 
hierarchy. At the center is the specified module. Each successive band 
of modules from the center to the left shows the calling modules; each 
successive band to the right shows the called entry points. The left 
(calling) modules reside on the library; the right (called) modules can 
include modules external to the AVFS library. A summary of this report 
is provided by the invocation summary report. More detailed information 
about modules and statement numbers containing invocations can be found 
in the externals cross reference. This report is produced for modules 
analyzed during an AVFS run. The default level of two may be changed by 
using the command: REPORT 3 B/n where n may be any integer from 1 to 
5. 


Figure 4.10a. FORTRAN Invocations Band 
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CALLING TREE MODULE VOTER 








PAGE 

1 





LEVEL 

-9 

-8 

-7 

-6 

-5 

-4 -3 

-2 

-1 

0 

+1 

+2 


NEWPROC 


ROBERT 1 

XPROC 

ROBERT1 


NEWPRO 

( C 2 ) 


XPROC 
ROBERT 1 

XPROC 
ROBERT 1 

XPROC 
ROBERT 1 


yppnr 


This report shows the selected module in a calling tree. At the 
center is the specified module. The left hand modules are the calling 
modules. The right hand modules are the called modules. A summary of 
this report is found in the invocation summary report. The statement 
numbers containing invocations can be found in the global cross refer- 
ence. 


Figure 4.10b. AED Invocations Band 
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COMMON MATRICES 


LEGEND <C"FIRST USED IN A CALL » E=EQU I U ALENCED * S=SET f U=USED » X^SET AND USED) 



** 

* 





1 

• 


* 


* 

X MODULE 

X 

N 

p 

p 

p 

P . G 

I 

* 


X 

* 

X 

E 

R 

u 

u 

U.E 

s 

* 


* 

X 

* 

X 

E 

T 

T 

T.T 

R 

X 


* 

X 

* 

T 

V 

A 

B 

B.B 

T 

X 


* 

X 

* 



T 

E 

O.L 

A 

X 


* 

* 

* 




F 

T.K 

B 

X 


* 

* 

* 





• 


X 

COMMON 

* 

SYMBOL * 

X 





. 


X 


* 

** 





• 


X 

AIS70 

* 

FLCXXX 

X 

U 

U 

U 

U 

u’.u 

U 

X 


X 

FNUXXX 

* 

U 

u 

U 

u 

u.u 

U 

X 


X 

FRGXXX 

* 

U 

u 

U 

u 

u.u 

U 

X 


* 

FSZXXX 

* 





.u 

C 

X 


* 

ICHXXX 

X 



s 

s 

s.s 


X 


* 

IXXXXX 

* 

X 

X 

X 

X 

x.x 

X 

X 


* 

LNGXXX 

* 

U 

u 

u 

u 

u.u 

u 

X 


X 

MAXXXX 

* 





.X 


X 



** 

* 





X 


X 

X MODULE 

* 

B 

p 

p 

s 

X 


X 

X 

X 

L 

A 

T 

D 

X 


X 

X 

X 

D 

s 

R 

B 

X 


X 

X 

X 

S 

T 

S 

A 

X 


X 

X 

X 

D 

U 

T 

S 

X 


X 

X 

X 

B 

0 

R 

A 

X 


X 

* 

X 





X 

COMMON 

X 

SYMBOL X 

X 





X 


X 






X 

SDB 

X 

ISCODE 

X 

X 

X 

U 

S 

X 


X 

ISCONT 

X 

U 

X 



X 


X 

ISINDT 

X 



S 


X 


X 

ISINFO 

X 

s 

s 


X 

X 


X 

ISLABL 

X 

E 

E 

E 

E 

X 


X 

ISLONG 

X 

X 

X 


X 

X 


X 

ISPTR 

X 


X 

S 

X 

X 


X 

ISTYPE 

X 

s 

X 

U 

X 

X 


The common matrices report lists symbols which are used by at 
least one of the modules on the restart file. The symbol usage is 
explained in the legend at the top of the report; a blank space indi- 
cates that the symbol is not used in any way in that particular module. 
The symbols within each common are listed alphabetically in this report. 
Only modules which use at least one variable of a common block will 
occur in the matrix for that common. This report includes all commons 
and modules on the restart file. An updated version of this report may 
be produced by reanalyzing all changed modules and using the EXPAND 
option. When all modules in a software system have been entered onto a 
RESTART file, this report can be used to check for global set/use 
inconsistencies. A row of one or more U f s indicates that a common 
variable is used but not set. A row of one or more S f s indicates a 
common variable which is set but not used. A common variable which is 
not included in the matrix is never referenced in an executable state- 
ment. The statement numbers where common variables are referenced can 
be found in the common variable cross reference report. 


Figure 4.11. FORTRAN Commons Matrices 
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THE FOLLOWING MODULES CONTAIN I/O STATEMENTS 


A1IO 

IFTRAX 


I/O STATEMENTS AND ASSOCIATED FORMATS 


A1IO 


STMT NEST 

LINE 

SOURCE.. . 

...SOURCE TAB 

3 

16 

READ<UNIT,901 

A1I0 17 

3 

17 

1 ) (TEXT(I) »I*liLEN> 

A1I0 18 


18 

C END-FILE TEST 

A1I0 19 

12 

29 

URITE < UNIT. 901) (TEXTC I) , I-l.LEN) 

AlIO 30 


30 

C 

A1I0 31 

23 

48 

901 FORMAT (132A1) 

AlIO 49 

IFTRAX 

— 



STMT NEST 

LINE 

SOURCE... 

...SOURCE TAB 

17 

25 

READ ( IN. 900 ) KNDEWT, KCONV. KOCOM, KFORIN, KIN. KOUT , KOUTC 

IFTRAX26 

17 

26 

* KENCRD, KNLINE. KSAVE 

IFTRAX27 

18 

27 

900 FORMAT < 12,311.613 ) 

IFTRAX28 

44 

51 

URITE<I0UT.901> NCARD. NERR 

IFTRAX32 

43 

32 

901 FORMAT < / 23H STRUCTRAN-1 STATISTICS 

IFTRAX 33 

45 

33 

1 / 1X.I6.20H CARDS READ 

IFTRAX34 

45 

54 

2 / 1X.I6.20H ERROR ( S ) FOUND 

IFTRAX33 

45 

53 

* ) 

IFTRAX36 


This report provides a list of all the program modules in which 
any type of READ or WRITE statement appears • The source statements are 
reproduced along with the defining FORMAT. This report may be used to 
locate all the points where variables are being input or output from the 
system. This report is produced only for source text which is analyzed 
during an AVFS run. 


Figure 4.12. FORTRAN I/O Statements 





CROSS REFERENCE 


NAME SCOPE MODULE USED/SET /EQUIVALENCED < * INDICATES SET ) 


AIDBG 

DBGCGM 

ISRTAB 

82 









CORE 


GETDLK 

26E 











ISRTAB 

25E 











NEXT 

1SE 











PREV 

18E 











PUT AT 

18£ 











PUT6EF 

18E 











PUTBOT 

18E 









FLCXXX 

AISTO 

GETBLK 

144 

190 

231 

244 







AISTO 

ISRTAB 

67 










AISTO 

NEXT 

3? 










AISTO 

PREV 

39 










AISTO 

PUTAT 

33 










AISTO 

PUTBEF 

43 










AISTO 

PUTBOT 

43 









FNUXXX 

AISTO 

GETBLK 

142 

187 

227 

261 







AISTO 

ISRTAB 

62 










AISTO 

NEXT 

34 










AISTO 

PREV 

34 










AISTO 

PUTAT 

30 










AISTO 

PUTBEF 

40 










AISTO 

PUTBOT 

40 









FRGDIR 

POOLCM 

GETBLK 

149* 

193* 

240* 

248* 







POOL CM 

ISRTAB 

79* 










POOLCM 

NEXT 

43* 










POOLCM 

PREV 

43* 










POOLCM 

PUTAT 

38* 










POOLCM 

PUTBEF 

50* 










POOLCM 

PUTBOT 

50* 









FRGXXX 

AISTO 

GETBLK 

148 

192 

240 

268 







AISTO 

ISRTAB 

79 










AISTO 

NEXT 

43 










AISTO 

PREV 

43 










AISTO 

PUTAT 

38 










AISTO 

PUTBEF 

50 










AISTO 

PUTBOT 

50 









FSZXXX 

AISTO 

GETBLK 

140 

141 

133 

186 

216 

219 

220 

248 

249 


AISTO 

ISRTAB 

64 









ICHXXX 

AISTO 

GETBLK 

56* 

* 

H 

00 

►-* 

CD 

« 

148* 

235* 






AISTO 

PUTAT 

35* 










AISTO 

PUTBEF 

47* 










AISTO 

PUTBOT 

47* 









IXXXXX 

AISTO 

GETBLK 

147* 

147 

149 

191* 

191 

193 

237* 

239 

240 267* 267 268 


AISTO 

ISRTAB 

78* 

78 

79 








AISTO 

NEXT 

42* 

42 

43 








AISTO 

PREV 

42* 

42 

43 








AISTO 

PUTAT 

37* 

37 

38 








This multi-module report shows where variables in common blocks 
are used, set or equivalenced. The report is alphabetically ordered by 
the name of the common variable. The common block which contains the 
variable is indicated in the scope column. Modules which reference the 
common variable are alphabetically ordered in the module column. 
Statements (AVFS statement numbers) within each module are shown next. 
A blank following the statement number indicates the variable is used 
there, a f * f indicates the variable is set, and an *E r indicates the 
variable is equivalenced. This report is produced for all modules and 
all commons on the restart file. An updated version may be obtained by 
reanalyzing all changed modules and using the EXPAND option. A summary 
of the information in this report is provided in the common matrices 
report. 


Figure 4.13. FORTRAN Commons Cross Reference 
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CROSS REFERENCE 


NAME 

SCOPE 

MODULE 

USED/SET/EQUI 1 

EROR 

EXTERNAL 

ISRTAB 

87 



FREL.NK 

EXTERNAL 

PUTDEF 

31 




EXTERNAL 

PUTBOT 

29 

31 


GETFRG 

EXTERNAL 

GETBLK 

262 




EXTERNAL 

ISRTAB 

63 




EXTERNAL 

NEXT 

37 




EXTERNAL 

PREY 

37 




EXTERNAL 

PUTAT 

31 




EXTERNAL 

PUTBEF 

41 




EXTERNAL 

PUTBOT 

41 



IGTURD 

EXTERNAL 

NEXT 

31 

33 



EXTERNAL 

PREV 

31 

33 



EXTERNAL 

PUTBEF 

32 




EXTERNAL 

PUTBOT 

35 



ITSFRG 

EXTERNAL 

ISRTAB 

60 




EXTERNAL 

NEXT 

35 




EXTERNAL 

PREV 

35 




EXTERNAL 

PUTAT 

29 




EXTERNAL 

PUTBEF 

39 




EXTERNAL 

PUTBOT 

39 



LGTMLT 

EXTERNAL 

ISRTAB 

52 

53 


MAKFRG 

EXTERNAL 

GETBLK 

224 



MINO 

EXTERNAL 

ISRTAB 

66 



PUTURD 

EXTERNAL 

PUTBEF 

33 

35 

37 


EXTERNAL 

PUTBOT 

32 

36 

38 

XMIT 

EXTERNAL 

GETBLK 

45 

55 

234 


EXTERNAL 

NEXT 

40 

46 



EXTERNAL 

PREV 

40 

46 



EXTERNAL 

PUTAT 

34 




EXTERNAL 

PUTBEF 

44 




EXTERNAL 

PUTBOT 

44 




( * INDICATES SET ) 


This multi-module report shows the AVFS statement number where 
each external is referenced. The report is alphabetically ordered by 
the name of the external. Modules which reference the external are 
alphabetically ordered in the module column. Statements (AVFS statement 
numbers) within each module are shown in the next column. This report 
is produced for all modules on the restart file. An updated version may 
be obtained be reanalyzing all changed modules and using the EXPAND 
option. A summary of information contained in this report is provided 
by the Invocation Summary Report. The text of each invocation can be 
found by referring the AVFS statement listing or Invocation Report for 
each module. Note that these reports are not generated from the restart 
file but rather from source analyzed during an AVFS run. 


Figure 4.14a. 


FORTRAN Externals Cross Reference 
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CROSS 

REFERENCE MULTI 

-MODULE REPORT 

PAGE 1 

NAME 

CLASS 

MODULE 

USED/SET ( - INDICATES SET ) 


Cl 

COMMON 

VOTER 

71 


C2 

COMMON 

VOTER 

71 


C3 

COMMON 

VOTER 

71 


C4 

COMMON 

VOTER 

76 


CC1 

COMMON 

VOTER 

9 


CC2 

COMMON 

VOTER 

9 


El 

EXTERNAL 

VOTER 

72 


E2 

EXTERNAL 

VOTER 

72 


E3 

EXTERNAL 

VOTER 

72 


E4 

EXTERNAL 

VOTER 

73 


E5 

COMMON 

VOTER 

78 


E6 

COMMON 

VOTER 

78 


EE1 

EXTERNAL 

VOTER 

14 



In 

EE 2 

EXTERNAL 

VOTER 

14 






’vj 

NEWPROC 

EXTERNAL 

ROBERT 1 

85 

97 

117 





NOCALLFROM 

EXTERNAL 

NOCALLFROM 

88 

94 






PROC1 

EXTERNAL 

VOTER 

10 

46 






PROC2 

EXTERNAL 

VOTER 

13 

46 






PROCCALL1 

EXTERNAL 

VOTER 

39 

40 

41 

42 

43 

44 106 108 111 115 


PROCCALL2 

EXTERNAL 

VOTER 

46 

110 

113 





R1 

EXTERNAL 

VOTER 

11 

12 






ROBERT 1 

EXTERNAL 

ROBERT 1 

82 

98 






ROBERT 2 

EXTERNAL 

ROBERT2 

100 







VOTER 

EXTERNAL 

VOTER 

5 

41 

43 

44 

45 

45 -61 


XPROC 

EXTERNAL 

ROBERT 1 

86 

92 






Figure 4.14b. AED Global Cross Reference 



Figure 4.14b continued 


This multi module report shows the AVFS statement number where 
each global variable is referenced. The report is alphabetically 
ordered by the name of the global variable in the first column. The 
class column denotes whether the variable is EXTERNAL or in COMMON. 
The moudles which reference the global variable are alphabetically 
ordered in the module column. The remaining columns contains the line 
numbers within each module where the variable is referenced. 
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The PICTURE report can only be obtained by using the REPORT^PIC- 
TURE command; it is not included in any of the options because the 
PICTURE report has limited use for structured source programs. The 
primary function of this report is to delineate the control flow of 
FORTRAN programs. The downward flows are shown on the right of the 
report. The upward flows are shown on the left. The B stands for the 
start of a path and the E stands for the end of a path. This report is 
especially helpful in breaking down large FORTRAN programs into smaller 
parts that are more manageable to restructure. Since the PICTURE report 
shows the beginning and ending of paths, it helps the user determine 
which are logically cohesive sections of code. 


Figure 4.15. FORTRAN Picture of Module Structure 
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FLOWGRAPH 


PROCEDURE YAW. ENG 


UPWARD JUMPS 
ABCDEFGHIJK 


STATEMENT TEXT 


DOWNWARD JUMPS 

ABCDEFGHIJK 


DEFINE PROCEDURE YAW. ENG TO BE 
BEGIN 

Y. FAIL. MON =PGM.V AND NOT YAW. SAS. 2FAIL ; 
IF Y.TEST. COMPL 

THEN BEGIN 

IF IN.CH.A 

THEN BEGIN 

ASNB IT (Y . FAIL .MON , 8 , DO . BUFF . 3 ) ; 
END 

ELSE 

ASNB IT (Y.FAIL.MON, 5,DO.BUFF. 3 ) ; 
END; 

GSP.V =■ REFBIT (13 ,CD. 15. MA); 


EB 
B 
. . 
.EB 

B. 


..E 

.E 


Figure 4.16. AED Picture of Module Structure 
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4. 4 SUMMARY 

The SUMMARY option is intended to be used when a brief introduc- 
tion to a module or a set of modules is desired. For FORTRAN it 
provides an analysis of source statements, common blocks, and entry 
points. For AED it provides an analysis of source statements on a 
module basis. 

The statements of individual modules are classified according to 
categories which are appropriate to that language. Under each classi- 
fication a tabulated account of the various statement types are listed. 
An individual Statement Profile report with this information is gener- 
ated for each module. This report is shown in Fig. 4.17. 

For FORTRAN, the COMMONS report lists the common blocks in each 
module and a report index for multiple module analysis as was shown in 
Fig. 2.4. For AED, there is a single COMMON which is analyzed during 
interface analysis and reported on in the interface report (see Fig. 
4.5). 


An Invocation Summary Report is also generated for this option and 
for the document option as shown in Fig. 4.9b. 

PROFILE 

The AED statement profile report (Fig. 4.17b) lists the name of 
the module and the number of lines at the top of the report. The module 
name is the name of the procedure contained in the module. The number 
of lines includes the lines from any inserts and includes blank lines. 

AED statements are classified into declarations and statements. 
While there can be more than one declaration or statement per line. 
Typically there is less than one of each per line. Hence the number of 
declarations plus the number of statements will be less than the number 
of lines in most cases. 
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Under declarations, there are declarations for arrays, beads, 
commons, components, defines, externals, packs, presets, procedures, 
switches, synonyms, and variables. Each of these is counted separately. 
Inserts are listed under declarations but are not included in the count 
for declarations. In AED, the inserts normally contain declarations. 
The line percentage is computed on the basis of the total number of 
lines printed on the top of the profile. 

Under statements, there are assignment, compond, if, for, goto, 
procedure and while categories. A line can contain several categories. 
For example, a compound statement is made up a BEGIN. .END construct. 
Thus the module is counted as a compound statement. Then an IF state- 
ment often contains a BEGIN... END compound statement as well as a 
procedure invocation. 

Comments and asserts are listed under statements but are counted 
separately. 


FORTRAN 

Report Command 

Statement Profile OPT ION “SUMMARY 

(Fig. 4.17a) 


Invocation Summary OPTION“SUMMARY 

(Fig. 4.9a) 


Common Summary 


OPTION “SUMMARY 
(Fig. 4.18) 


AED 

Command 


GRC*PROFILE. PROFILE 
(Fig. 4.17b) 
Appendix C-20 

GRC*DEPEND. DEPEND 
(Fig. 4.9b) 

Appendix C-17 

GRC*INTER*INTER 
(Fig. 4.5) 

Appendix C-14 
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The FORTRAN command 


OPTION-SUMMARY 

may be replaced by the UNIVAC command 
@XQT,B GRC * AVFS . A VFS 

The complete UNIVAC JCL Is shown on page C-10* 

to produce the three reports at one time* The AED commands to produce 
the three corresponding reports are separate XQT commands* 
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STATEMENT PROFILE 


SUBROUTINE EXAMPL < INFO, LENGTH) 


INTERFACE CHARACTERISTICS 


ARGUMENTS 2 
ENTRY 1 
EXIT 1 
URITE 1 


STATEMENT STATEMENT 

CLASSIFICATION TYFE NUMBER PERCENT 


DECLARATION, . . 


FORMAT 1 2.8 



TOTAL 

1 

2.8 

EXECUTABLE. . . 

ASSIGNMENT 

4 

11.1 


BLOCK 

2 

5.6 


CALL 

1 

2.8 


CASEELSE 

1 

2.8 


DOUNTIL 

1 

2.8 


ELSE 

1 

2.8 


END 

1 

2.8 


ENDBLOCK 

2 

5.6 


ENDCASE 

1 

2.8 


ENDIF 

2 

5.6 


ENDUHILE 

2 

5.6 


INVOKE 

3 

8.3 


RETURN 

1 

2.8 


SUBROUTINE 

1 

2.8 


URITE 

1 

2.8 


TOTAL 

24 

66.7 

•DECISION. . . 

CASEOF 

1 

2.8 


CASE 

2 

5.6 


DOUHILE 

2 

5.6 


ENDUNTIL 

1 

2.8 


IF-THEN 

2 

5.6 


TOTAL 

8 

22.2 

DOCUMENTATION. . 

COMMENT 

3 

8.3 


TOTAL 3 8.3 


This report classifies each statement of a module as either a 
declaration, executable, decision, or documentation statement. Under 
these classifications, a tabulation of the statement types are listed. 

Figure 4.17a. FORTRAN Statement Profile 
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STATEMENT PROFILE 
module YAW. ENG 
number of lines 156 


number percentage of lines 


declarations 83 53.2 

array 0 0.0 

bead 1 0.6 

common 0 0.0 

component 1 0.6 

define 1 0.6 

external 25 16.0 

insert 3 1.9 

pack 0 0.0 

preset 0 0.0 

procedure 1 0.6 

switch 0 0.0 

synonym 2 1.3 

variable 52 33.3 

statements 45 28.8 

assignment 24 15.4 

comment 19 12.2 

compound 5 3.2 

if 6 3.8 

for 0 0.0 

goto 0 0.0 

procedure 11 7.1 

while 1 0.6 

assert 5 3.2 


AED statements are classified into declarations and statements. 
Under each classification, the type of statement is listed along with 
its number and frequency in terms of liens . The number of lines 

(including blank ilnes) in the module is listed. 


Figure 4.17b. AED Statement Profile 
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COMMON SUMMARY 


COMMON MOOULES WHICH IXCLUOE THE COMMON 


AISTO 

MAKTA8 



ALPHA 

CHATRX 



ANSI 

CMATRX 

REFVAR 


BLKSTO 

OEPVOK 



09GC0M 

MAKTAB 



OE PCOH 

OEP0NO 

OEPVOK 


EPT 

OEPGRP 

OEPVOK 

REFVAR 

FILES 

CMATRX 

0EP9N0 

OEPGRP OEPVOK XREFER 

GLOBAL 

0EP8N0 



HALPHA 

XREFER 



HCHARS 

OEPGRP 

XREFER 


HOIGIT 

CMATRX 



ICMMOS 

STEP15 



KOELMS 

OEPVOK 



HACHNE 

OEPVOK 



mo a 

OEPVOK 

REFVAR 


MMRY15 

STEP1S 



mthsto 

OEPGRP 

OEPVOK 


MTHST1 

OEPVOK 

XREFER 



This report lists all modules and all common blocks encountered. 


Figure 4.18. FORTRAN Common Summary 
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4.5 INSTRUMENT 

Figure 4.19 illustrates AVFS instrumentation of a FORTRAN or AED 
program to prepare it for an execution coverage test. There are three 
forms of instrumentation: 

• path instrumentation 

• trace instrumentation 

• assertion instrumentation 

In each case the instrumented modules will be written to a sequential 
file which must be compiled, loaded, and executed in the normal test 
environment. During execution, data is collected in a file (FORTRAN) or 
in memory (AED) for later analysis. Section 4.5.1 describes FORTRAN 
instrumentation and Sec. 4.5.2 describes AED instrumentation. 

4.5.1 FORTRAN Instrumentation 

Path Instrumentation 

During FORTRAN instrumentation, the instrumented modules will be 
written to UNIT 9 (LPUNCH). A DD path definitions report will be 
generated to aid in the interpretation of test results. The user should 
use the FIRSTLINE command (see Section 3.3) to specify the name of a 
FORTRAN compiler in a UNIVAC run stream command, and AVFS will auto- 
matically insert this specification as the first line of every sub- 
program. For example, if the FIN compiler will be used, the command 
should be : 

FIRSTLINE =* (@FTN,I TPF$.+). 
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Figure 4.19. AVFS Instrumentation of Source Code 
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A DD-path is a sequence of executable statements emanating from a 
decision statement and continuing to the next decision statement • Since 
complete DD-path testing means exercising all possible outways of 
decision statements, this is a more rigorous testing measure than 
exercising all program statements. All AVFS execution coverage reports 
are presented in terms of DD-paths, not statements. 

INSTRUMENT inserts a set of probe statements into each module. 
The probe statements are inserted into the source text at each entry and 
each exit of the modules and at each statement which begins a DD-path. 
Each probe includes a call to a data collection routine which records 
information concerning the flow of control in the executing module(s). 
A special probe is inserted at the end of the main program to signal the 
end of test execution. The user can also have this special probe 
inserted at other points in his code, which has the effect of breaking 
one test execution into multiple test cases. 

The instrumented source text along with an automatically supplied 
data collection routine is written to UNIT 9 (LPUNCH) in FORTRAN. The 
file is then compiled by a FORTRAN compiler. The instrumented object 
code is then ready for loading and test execution (Fig. 4.20). 

During execution of the instrumented program, the probes record 
execution data, which results from processing the set of test cases for 
this run, on UNIT 12 (LTEST) . If UNIT 12 is already assigned to a user 
file, the command, 

INSTRUMENT , PUNCH , PROBE , «f ile number> ) . 

will cause the data collected during execution to be written to the unit 
number specified. 

There is a special instrumentation command which allows the user 
to insert special probes into his instrumented code which delineate test 
cases within the test execution. The user specifies a statement within 
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COMPILATION 


EXECUTION 




Figure 4.20. Loading and Test Execution 
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a given module. Before each execution of this statement, the last test 
case is terminated and a new test case is begun. The form of the 
command for identifying a test execution boundary is: 

TESTBOUND .MODULE - «name>) , STATEMENT ** <number> 

where <number> is the AVFS statement number in module <name> where the 
test-case probe is to be put. The probe is inserted before the number 
specified; therefore, the number should be that of the first statement 
not to be included in the test case. Up to ten TESTBOUNDS may be 
specified during any one instrumented run. All must immediately follow 
the OPTIONS command (preceding all REACHING SET coranands). The output 
of this option when the LIST option is also specified is a DD-path 
Definitions report, as shown in Fig. 4.21. It is an indented source 
listing of an individual module with additional DD-path information. At 
each decision point, the DD-path generated is described in terms of its 
decision outways. When measuring testing coverage, the user can refer 
to this report to associate the DD-path definitions with his original 
source text. 

Commands 

INSTRUMENT, PUNCH, PROBE, (<file number>) . 

FIRSTLINE = (<run stream command>). 

OPTION - INSTRUMENT, LI ST. @XQT,IL GRC .AVFS. AVFS 

TESTBOUND ,MODULE=«name» , STATEMENT=<number> . 

See Appendix C-4 for a complete JCL example. 

Report 

DD-path Definitions (Fig. 4.21) 


(optional) 

(optional) 

(optional) 


71 



DO-PATH DEFINITIONS 


SUBROUTINE EXMft (HTa.LENGTH) 


STHT fcEST L DC SOURCE... ...SOURCE TAB 


1 


1 


3UBR0UTDC EXANPL ( DVO.LEWTH) 








2 

C 






OCAKPL2 



3 

C 

ILLUSTRATION OF DMA TRAN SYNTAX 





EXANTL3 



4 

c 






OWM.4 






tx 

DDPATH 

1 

IS PROCEDURE ENTRY 


2 


3 


IF <DVU.LC.10 .AND. LENGTH. GT.O)TVEM 





EXArtMJ 






n 

DDPATH 

2 

IS TRUE BRANCH 







o 

DDPATH 

3 

IS FALSE BRANCH 


3 

1 

4 


CALL CALLER < IfCO ) 





CW7U 

4 


7 


ELSE 





EXAMPL7 

3 

1 

8 


LEMJT>4*50 





EXAMPL8 

4 


7 


DO IF 





EXAPPL? 

7 


10 


CASE OF <INF0*4> 





EXAfVLIO 






« 

DDPATH 

4 

IS BRANCH OUTUAY 1 







a 

DDPATH 

3 

IS BRANCH OUTLAY 2 







o 

DDPATH 

4 

IS BRANCH OUTLAY 3 


• 


11 


CASE (14) 





EXMVL11 






n 

DDPATH 

7 

IS TRUE BRANCH 







ti 

DDPATH 

8 

IS FALSE BRANCH 


7 

1 

12 


LMT>44J>CTH-I>rO 





OCAMPL12 

10 


13 


CASE (17) 





DUYVL13 






n 

DDPATH 

7 

IS TRUE BRANCH 







a 

DDPATH 

10 

IS FALSE BRANCH 


11 

1 

14 


SO UHXLE <DVO.LT. 20) 





GUTPLIA 






it 

DDPATH 

11 

IS LOOP AGAIN 







a 

DDPATH 

12 

IS LOOP ESCAPE 


12 

2 

13 


DO UNTIL (LOKJTH.LE. INFO) 





EXAWL13 

13 

3 

14 


. . . I WOKE (OPUTE LENGTH) 





EXAMPL14 

14 

3 

17 


. . . IF (LENGTH. GE. 30) THEN 





EXAMPL17 






* » 

DDPATH 

13 

IS TRUE BRANCH 







a 

DDPATH 

14 

IS FALSE BRANCH 


13 

4 

19 


. INVOKE (PRINT-RESULTS) 





EXAMPL18 

14 

3 

17 


. . . END IF 





EXAMPL17 

17 

2 

20 


. END UNTIL 





EXATVL20 






a ODPATH 

13 IS LOOP ESCAPE 







a 

DDPATH 

14 

IS LOOP AGAIN 


18 

2 

21 


INFO-DVTHl 





EXAMPL21 

If 

1 

22 


. END UHILE 





EXA*PL22 

20 


23 


CAGE ELSE 





EXAMPL23 

21 

1 

24 


. DO MILE (LENGTH. GT .0) 





EXArtM_24 






a 

DDPATH 

17 

IS LOOP AGAIN 







a 

DDPATH 

18 

IS LOOP ESCAPE 


22 

2 

23 


I WOKE (COMPUTE LENGTH) 





EXA#VL23 

23 

1 

2* 


END LMIUE 





EXANPL24 

24 


27 


END CASE 





EXAMPL27 

23 


28 


BLOCK < PRINT-RESULTS) 





EXAMPL23 






a 

DDPATH 

17 

IS PROCEXPE ENTRY 


24 

1 

27 


miTt (4.1 > I>VO .LENGTH 





EXA4VUJ7 

27 

1 

30 


1 . FORMAT (10X.I3.20X, 13) 





EX/7VL30 

28 


31 


END BLOCK 





EXAMPL31 

27 


32 


BLOCK (COMPUTE LENGTH) 





EXAMPL32 






a 

DDPATH 

20 

IS PROCEDURE ENTRY 


30 

1 

33 


. LENGTH - LENGTH -10 





EXAM>L33 

31 


34 


END BLOCK 





E3WNPL34 

32 


33 


RETURN 





EXAMPL33 

33 


34 


END 






EXAMPL34 


This report is useful for testing purposes because it defines the 
decision paths • 


Figure 4*21* DD-Path Definitions 
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TRACE Instrumentation 


Additional information may be gathered during execution test by 
inserting INPUT and OUTPUT statements into each source module • The 
INPUT statements are used to list global variables (either parameters or 
in COMMON) that will have a value whenever the routine is entered; the 
OUTPUT statements are used to list variables that will be assigned a 
value in the routine. An INPUT variable may also be an OUTPUT variable. 
The INPUT/OUTPUT option provides a dynamic tracing of the values of the 
program variables. 

A type specification must be provided for each variable so the 
value will be printed the correct format. Omitted types will result in 
variables being printed according to the most recent previous type, and 
if there wasn’t a previous type the variable(s) will not be printed. 
The syntax to provide type information is : 

INPUT (/<type>/< variable list> ,/<type>/<variable list> , . . .) 

OUTPUT (/<type>/< variable list> ,/<type>/< variable list>,...) 

<type> may be REAL, INTEGER, HOLLERITH, or LOGICAL or the respective 
abbreviations for each, R, I, H, or L. <variable list> may contain 
non-subscripted variable names, array names, individual elements of an 
array, or an array subrange, such as (LIMIT(I), I * M,N) where LIMIT is 
an array with a dimension of at least N. I is a variable whose value 
will be undefined after the INPUT or OUTPUT statement is executed. 

Some examples are: 

INPUT ( / 1 /NUMBER , ( LIMIT (I) ,I=»M,N) ,/ R/ AREA , RANGE , 

* /L / DEBUG , / H/ TE ST ) 

OUTPUT (/REAL/ AREA, /LOGICAL/DEBUG) 

The INPUT and OUTPUT statements are turned into comments by AVFS 
so they may be left in the code when the instrumented code is compiled. 
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The INPUT/OUTPUT option also performs the same functions as the 
INSTRUMENT option so the instrumented code on UNIT 9 may be used in the 
same way as described in Sec* 4*5.1. 

The output of this option is the inclusion of a FORTRAN trans- 
lation of the INPUT and OUTPUT statements in the code written on UNIT 9 
(LPUNCH). When the program is executed, the names and values of the 
variables with type specifications listed in INPUT and OUTPUT state- 
ments, will be reported. In addition, a DD-path Definitions report 
identical to the one from the INSTRUMENT option will be generated, if 
the LIST option is also specified. Figure 4.22 shows this report for a 
subroutine with INPUT and OUTPUT statements. 

Command 

OPTION = INPUT/OUTPUT, LI ST. @XQT,TL GRC*AVFS.AVFS 


Report 


Input/Output Listing 


(Fig. 4.22) 



SUBROUT I « TlfCS < NUM. RESULT, SUM ) 

.. .SOURCE TAB 


1 


1 


2 

3 

4 

3 

4 
7 


8 

9 

10 

11 

12 

13 

14 
13 


This example shows INPUT and OUTPUT statements in the code. 


Figure 4.22. Input/Output Listing 


1 SUBROUTINE TIMES ( NUM, RESULT, SUM ) 

2 

3 

4 

3 C USING ADDITION TO MULTIPLY 

« DOPATH 1 IS PROCEDURE ENTRY 

7 INTEGER RESULT, SUM, Y 

8 IHVT </I/ HUM, RESULT ) 

9 

10 SUM -O 

11 Y “ NUN 

12 DO UHILE < Y .GT. 0 > 

O DOPATH 2 IS LOOP AGAIN 
** DDPATW 3 IS LOOP ESCAPE 

1 13 SUM ■ SUM RESULT 

1 14 . Y * Y - 1 

t 13 

14 END WHILE 

17 OUTPUT (/I/ SUM ) 

18 

1? RETURN 

20 END 


DO-PATH DEFINITIONS 
STMT NEST LINE SOURCE... 
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ASSERT Instrumentation 

Checks on variables during execution test can be obtained by 
inserting ASSERT statements into each source module. The ASSERT 
statements present logical conditions which are assumed to be true. If 
an assertion goes false, a report giving the module and line number of 
the false assertion will be printed. 

The syntax to provide assertions is: 

ASSERT ( boolean expression ) 

Some examples are: 

ASSERT ( HEIGHT .GT. MIN) 

ASSERT ( DELAY .LT. MAX .AND. DELAY .GT. MIN) 

The ASSERT statements are turned into comments by AVFS so they may 
be left in the code when the instrumented code is compiled. 

The ASSERT option performs the same functions as the INSTRUMENT 
option so the instrumented code on Unit 9 may be used in the same way as 
described in Sec. 4.5.1. 

The output of this option is the inclusion of a FORTRAN trans- 
lation of the INPUT and OUTPUT statements in the code written on UNIT 9 
(LPUNCH). When the program is executed, assertion violations will be 
recorded along with their location. Figure 4.23 shows a listing of a 
subroutine with ASSERT statements. 

Command Report 

OPTION=ASSERT ,LIST • Assert Listing (Fig. 4.22) 
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I 


sco nest source program xponch ( Input f output, tape* 

i Program xpcnen < input, output, tapes a output > 

i CASON 

i CUN1T 6 

4 CROON XPCNEN 

5 C 

6 c exponentiation bt multiplication using 

7 c subroutine tikes 

6 C 

9 integer answer, result, sum 


1& 



Initial (.true.) 

11 



PRINT 1 

12 


1 

Format <*i >huk iexpcn answer *> 

15 



00 

( M = 1, 4 ) 

V* 

1 


• 

READ 2, NUM. IEXPON 

15 

1 

2 

• 

FORMAT ( 2(15) ) 

16 

1 


• 

ASSERT ( NUM .G£. 0 , ANO • IEXPON .GE. 0 ) 

17 

1 


• 

RESULT = 1 

18 

1 


• 

I = 1 

15 

1 


• 

WHILE ( I ,LT. IEXPON ) 

20 

2 


• 

. ASSERT ( RESULT .EC. NUM »* I .ANO, NUM .GE. Q 




* • 

, .AND. IEXPON .GE. 0 » ANO, 1 .IT. TEXPON ) 

21 

2 


• 

. CALL TIMES ( NuN, RESULT. SUM ) 

22 

2 


• 

. RESULT = SUM 

23 

2 


• 

. 1 = 1 + 1 

2H 

1 


• 

ENO WHILE 

25 

1 


• 

answer = result 

k 6 

1 


• 

FRiNT 3, NUN. IEXPON. ANSWER 

27 

1 

3 

t 

FORMAT ( 3(IB) ) 

2b 



EnO 

00 

25 



final ( answer ,eq. num ** iexpon i 

50 



stop 

31 



EnO 



Figure 4.23. 


FORTRAN Assert Instrumentation 


OUTPUT I 
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4.5.2 AED Instrumentation 
Path Instrumentation 

During AED instrumentation, the instrumented module is written to 
UNIT 30 (INSTFL). A DD path definitions report is generated to aid in 
interpreting test results. The instrumented code is ready for compiling 
by an AED compiler. The instrumented object code is then ready for 
loading and test execution. 

Also during instrumentation, a special AED problem routine is 
generated on the file named PROBE. This routine must be compiled and 
loaded with the instrumented modules. During executiton of the instru- 
mented program, the AED probe progam records the test history in the 
memory of the CAPS computer. After execution halts, this information is 
sent to the PDP 11/60 for analysis. 

Command Report 

@XQT GRC*INST. INST DD path definitions (Fig. 4.24) 

See Appendix C-21 for a complete JCL example. 
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1 DEFINE PROCEDURE YAW. ENG TO BE 
PATH 1 

2 BEGIN 

3 Y. FAIL. MON - PGM.V AND NOT YAW . SAS . 2FAIL ; 

4 IF Y. TEST. COMP 

5 THEN BEGIN 
PATH 2 

6 IF IN.CH.A 

7 THEN BEGIN 


PATH 3 

8 

9 

10 


ASNBIT (Y .FAIL .MON , 8 , DO . BUFF . 3 ) ; 
END 

ELSE 


PATH 4 

11 ASNB IT (Y. FAIL. MON, 5, DO. BUFF. 3) 

PATH 5 
PATH 6 


PATH 7 

12 


END; 


GSP . V=REFB IT ( 1 3 , CD . 1 5 . MA ) ; 


Figure 4.24. AED Path Definitions 


79 



Trace Instrumentation 


Additional information may be gathered during execution test by 
inserting INPUT and OUTPUT assertions in each source module as was 
discussed for FORTRAN. In AED these assertions are written as COMMENTS 
in the following syntax: 

COMMENT INPUT <type><variable>; 

<type> may be one of the AED data types 
<variable> is one of the AED data names • 

During execution the value of the variable will be stored along 
with the execution time, the module name, and the statement number. All 
this information is sent to the PDP 11/60 for later analysis during 
execution test. 

Figure 4.25 shows a listing of some source with AED INPUT/OUTPUT 
assertions. 

Command Report 

@XQT GRC*TRACE. TRACE Trace assertion report (Fig. 4.25) 

See Appendix C-22 for a complete JCL example. 


1 BEGIN 

2 BOOLEAN ALIGN; 

3 BOOLEAN ROLL. OUT; 

4 COMMENT INPUT BOOLEAN ALIGN; 

5 COMMENT OUTPUT BOOLEAN ROLL. OUT; 

6 

7 ROLL. OUT = ALIGN OR ROLL. OUT; 

8 END FINI 


Figure 4.25. Trace Assertion Report 
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Assert Instrumentation 

Checks on AED variables during execution can be obtained by 
inserting ASSERT statements into each source module. In AED these 
assertions are written as COMMENTS in the following syntax: 

COMMENT ASSERT boolean-expression; 

Some examples of assertions are: 

COMMENT ASSERT HEIGHT > MIN; 

COMMENT ASSERT TIME < MAX; 

The output of the assertion command is instrumented code on UNIT 
30 which may be compiled, loaded, and executed. 

During execution false assertions will be saved in the CAPS and 
sent to the PDP 11/60 when some maximum number (presently 30) of false 
assertions have been detected. 

Command Report 

@XQT GRC* ASSERT. ASSERT Assert Listing (Fig. 4.26) 

See Appendix C-23 for a complete JCL example. 


1 BEGIN 

2 BOOLEAN ALIGN; EXTERNAL ALIGN; 

3 BOOLEAN ROLL. OUT; EXTERNAL ROLL. OUT; 

4 COMMENT ASSERT ROLL. OUT; 

5 COMMENT ASSERT ALIGN AND ROLL. OUT; 

6 ALIGN = FALSE; 

7 END FINI 


Figure 4.26. AED Assert Listing 
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4.6 REACHING SET 

The analysis specified by the REACHING SET option executes the 
module retesting assistance capability of AVFS. Presuming that a set of 
untested DD-paths has been isolated, AVFS helps the user identify 
sections of code to exercise. The user specifies the desired DD-path 
number to be "reached, 11 and AVFS generates the reaching set of paths 
from module entry or from a designated DD-path up to the second DD-path 
number which has been specified. The user may specify either iterative 
(explained below) or non-iterative reaching sets to be generated. AVFS 
prints a list of DD-paths on the reaching set. With this output, the 
user is able to identify which parts of the program need to be executed 
(and therefore which program values need to be modified) in order for 
the selected DD-path to be executed (or reached). Once this determi- 
nation is made, new test cases can be constructed, and the program can 
be run again to execute the DD-paths which were not traversed in the 
previous tests. 

The FORTRAN command 

OPTION - REACHING SET 
or the AED command 

@XQT GRC*REACH. REACH 

enables reaching set analysis to be performed. However, no analysis is 
performed unless one or more reaching sets are specified. The command 
for specifying a reaching set is: 

REACHING SET, MODULE- (<name>),TO= <DD-path number>, 

FROM- <DD-path number> {, ITERATIVE). 

The reaching set which includes all possible iterative paths may be 
generated by appending ITERATIVE (preceded by a coma) to this command, 
otherwise the command generates a non-iterative reaching set. 
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A Reaching Set report is in Fig. 4.27; it lists the set of 
DD-paths within the reaching set, followed by the source statements 
which make up that set of paths. 

FORTRAN Command Report 

OPTION ■ REACHING SET Reaching Set (Fig. 4.27a) 

See Appendix C-27 for a complete JCL example 


AED Command Report 

@XQT GRC*REACH. REACH Reaching Set (Fig. 4.27b) 

See Appendix C-24 for a complete JCL example 
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REACHING SET ANALYSIS 


SUBROUTINE EXAMPL < INFO, LENGTH) 


NON-ITERATIVE REACHING SET FROM DD-PATH 3 TO DO-PATH 14 

DDPATHS IN REACHING SET 

3 4 3 8 9 11 14 


SOURCE CODE IN REACHING SET 


2 


3 

*IF 

(INFO.LE. 10 .AND, LENGTH . GT . 0 ) THEN 


4 


7 

'else 


5 

1 

8 

, 

LENGTH-50 


6 


9 

END 

IF 


7 


10 

CASE OF < INFO+6) 


8 


11 

CASE (14) 


10 


13 

'CASE (17) 


11 

1 

14 


DO WHILE (INF0.LT.20) 


12 

2 

15 


. DO UNTIL ( LENGTH. LE. INFO) 


13 

3 

16 

. 

. . INVOKE (COMPUTE LENGTH) 


14 

3 

17 

• 

. . IF (LENGTH. GE. 30) THEN 

**TAT<GET DD-PATH BEGINNING** 

16 

3 

19 


. . END IF 


17 

2 

20 

. . . 

. END UNTIL 



This report shows which DD-paths must be traversed, beginning with 
a specified DD-path to reach the target DD-path. Both the beginning and 
the ending DD-path numbers are designated by the user in the REACHING 
SET specification command. Coordination of this report with DD-Path 
Definitions report allows the user to determine what values must be 
supplied to the variables to affect the decision predicates so the 
appropriate path will be taken. 


Figure 4.27a. FORTRAN Reaching Set 
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BRSET. LOG; 1 


17— MAY— 1982 16:49:58.76 


Page 3 


REACHING SETS FOR MODULE YAW. ENG 


1. REACHING SET FROM STATEMENT 0 TO STATEMENT 0 


*♦♦*♦♦■»*** REACHING SET ERROR ********** 

ILLEGAL INPUT STATEMENT NUMBERS. . . NO COMPUTATION PERFORMED. 

************************* «H»*****"**-I*--****** 


HERE ARE THE STARTING AND ENDING STMT NUMBERS 
FOR PROCEDURES IN THIS MODULE; 

l. PROCEDURE YAW. ENG FROM STMT 14 TO STMT 83 


2. REACHING SET FROM STATEMENT 14 TO STATEMENT 50 


STMTS 

IN 

REACHING 

SET 

NO. 

1: 

14 

15 

16 

17 

18 

19 

20 







33 

34 

35 

36 

37 

38 

39 







40 

41 

42 

44 

45 

46 

47 







48 

49 

50 





STMTS 

IN 

REACHING 

SET 

NO. 

2: 

14 

15 

16 

17 

18 

19 

20 







33 

34 

35 

36 

37 

38 

39 







40 

41 

43 

44 

45 

46 

47 







48 

49 

50 





STMTS 

IN 

REACHING 

SET 

NO. 

3: 

14 

15 

16 

17 

18 

19 

20 







21 

22 

23 

24 

25 

26 

27 







33 

34 

35 

36 

37 

38 

39 







40 

41 

42 

44 

45 

46 

47 







43 

49 

50 





STMTS 

IN 

REACHING 

SET 

NO. 

4: 

14 

15 

16 

17 

18 

19 

20 







21 

22 

23 

24 

25 

26 

27 







33 

34 

35 

36 

37 

38 

39 







40 

41 

43 

44 

45 

46 

47 







48 

49 

50 





STMTS 

IN 

REACHING 

SET 

NO. 

5; 

14 

15 

16 

17 

18 

19 

20 







21 

22 

28 

29 

30 

31 

32 







33 

34 

35 

36 

37 

38 

39 







40 

41 

42 

44 

45 

46 

47 







48 

49 

50 





STMTS 

IN 

REACHING 

SET 

NO. 

6: 

14 

15 

16 

17 

18 

19 

20 







21 

22 

23 

29 

30 

31 

32 







33 

34 

35 

36 

37 

38 

39 







40 

41 

43 

44 

45 

46 

47 


Figure 4.27b. AED Reaching Set 
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4.7 FORMAL VERIFICATION 

Two steps are required to perform symbolic execution or veri- 
fication condition generation. The first is a preliminary step to 
obtain necessary data, the second is the actual generation. 

The formal program verifier uses the program paths of a module to 
perform symbolic execution or verification condition generation of 
FORTRAN programs. In AED programs, line numbers are used instead. 

4.7.1 FORTRAN Verification 

For a preliminary analysis of a FORTRAN program, the command is 

OPTION = VCG. 

This option generates a DD path definitions report as was shown in Fig. 
4.21. 


The command to generate a verification condition is 

VCG,PATH=<number of paths>,<path list> 

where the path list consists of a set of DD path numbers. For example, 
the command to cover the path from program entry to the first decision 
statement would be 

VCG ,PATH=*1 , 1 

To cover DD paths 2,4 in a loop construct, the consnand would be 

' VCG ,PATH=2 ,2 ,4 

Usually several paths are processed at once. 

The DD-Path Definitions Report for the subroutine CIRCLE, Fig. 
4.28, shows three DD-path numbers. The IF statement provides two 

alternative paths, DD-path 2 when the IF expression is evaluated as 
" true'* and DD-path 3 when it is "false" . 
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Figure 4.28. DD Path Definitions for Verification 


For each of these two paths, it is necessary to provide a VCG,PATH 
command. The commands for generating the verification conditions for 
CIRCLE would be: 

OPTION = VCG. 

MODULE = (CIRCLE). 

VCG, PATH = 2,1,2 
VCG, PATH = 2,1,3 

As a result of these commands, a verification path and a verifi- 
cation condition will be generated as shown in Fig. 4.29. 
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VCS«PATHs2'l«2. 


subroutine circle ( racius# height# area# volume ) 


LINE 


PATH SOURCE TEXT 


1 


SUBROUTINE CIRCLE l RACIUS# HEIGHT# AREA# VOLUME ) 


* 

5 

6 
7 

S I 
9 ( 
11 
12 


1) 

1) 


initial ( raozus #gt. o ) 

VOLUME = 0 

AREA : FI « RADIUS *• 2 
IF ( AREA #GT# KAOILS ) 

« VOLUME = HEIGHT • AREA 
• PRINT 1* t RAQIUS « VOLUME > 

ENOIF 

FINAL ( VOLUME .EQ# 0 #OR# VOLUME #EO. HEIGHT * AREA ) 


Verification Path 


stmbolicallt execltlc verification conoiticn 

line VERIFICATION CONOITICN 

% RADIUS • GT* 0 

ANC 

7 PI • ( RAOXUS •• 2 ) #GT# RADIUS 

- — — implies ----- 

12 HEIGHT • PI * I HALIL* •* 2 ) #Eb# U #OR# HEIGHT • Pi * < RAOXUS •• 2 

) • EG# HEIGHT • PI * < RAQIUS •• 2 I 


Verification Condition 


Figure 4 #29. Verification Condition Generation 
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The VCG EXPRESSION command together with the previous path command 
allows the symbolic execution of a given expression over a specified 
path. 

Command 

VCG, EXPRESSION 
<expression> $ 

VCG, PATH <number of paths>,<path list> 

Some samples of commands are: 

OPTION-VCG 
MODULE- (EXAMPL) . 

VCG, EXPRESSION 
VOLUME 

VCG, PATH-3, 1,2, 3 
VCG, EXPRESSION 
DIAMTR ,GT. HEIGHT $ 

VCG, PATH-3, 2, 5, 3 

4,7,2 AED Verification 

AED Verification is similar to FORTRAN verification except that 
lines are specified instead of paths. 

To symbolically execute an expression C.F.LCH over lines 10, 11, 
12 one specifies during the execution of GRC*VCG.VCG: 

FOR LINES - 10, 11, 12 DO 
C.FO.LCH 
END FOR 

This would result in the report shown in Fig, 4.30 which lists the 
original expression, the specified lines, and the executed expression. 
A range of lines is specified by 

first line •• last line 
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so the previous command could be 


FOR LINES =■ 10.. 12 DO 
C.FO.LCH 
END FOR 


SYMBOLIC EXECUTION REPORT 
ORIGINAL EXPRESSION 

C.FD.LCH 
SOURCE CODE 

10 ALIGN =* TRUE; 

11 RUN. WAY = FALSE; , 

12 C.FD.LCH - ALIGN OR C.FD.LCH; 

FINAL EXPRESSION 
TRUE OR C.FD.LCH 


Figure 4.30. AED Symbolic Execution Report 
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To generate a verification condition, it is necessary to specify 
assertions at each end of the path to be verified. By specifying VCG as 
the expression to be symbolically executed, a verification condition 
will be generated using assertions previously placed in the text. 
Figure 4.31 illustrates an AED verification condition report listing the 
source and verification condition. The command to generate the figure 
would be 


FOR LINES 9.. 12 DO 
VCG 
END FOR. 


SOURCE CODE 


9 COMMENT ASSERT GLIDE SLOPE > 2 AND RANGE > 1000; 

10 

11 ALTITUDE = RANGE * GLIDE SLOPE * 3.14159/180.0; 

12 COMMENT ASSERT ALTITUDE >30; 

VERIFICATION CONDITION 

GLIDE SLOPE > 2 AND RANGE > 1000 

IMPLIES 

RANGE * GLIDE SLOPE * 3.14159/180.0 > 30 


See Appendix C-28 for a complete JCL example. 


Figure 4.31. AED Verification Condition Report 
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5 AVFS* CONSTRAINTS 

AVFS imposes certain restrictions on the size of the interface 
file, the command language, and the source text to be analyzed. Most of 
the limitations based on size are generous (e.g., the maximum number of 
nested IF statements is one hundred). AVFS is capable of handling quite 
large source text files. Unusually large programs may have to be 
processed by several successive executions, each operating on a separate 
file of modules. 

5.1 UNIVERSAL CONSTRAINTS 

• At most 250 modules may use the same common block 

• Maximum of one card for any given command 

• Maximum of 24 commas in any given command 

• Maximum of 80 characters per source card image read 

• The maximum number of DD-paths which can begin at a state- 
ment is 50 

• The maximum number of statements on a single DD-path is 100 

• The sizes of the two random files UNIT 2 (LIBNEW) and UNIT 
13 (LIBWSP) are established using a DEFINE FILE statement in 
FAVS. The current sizes are 500 records (of 300 words each) 

• Maximum of 250 tokens per statement 

5.2 SYNTAX CONSTRAINTS 

The following implementation constraints are the current ones 
which must be observed: 

• Each module placed on the same interface library must have a 
unique name 

• If any errors are detected in the source, one or more 
statements may be flagged as hot parsed 
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Maximum nesting depth of 25 DOs in FORTRAN 

DELETE, START EDIT, STOP EDIT are not recognized 

Switch labels may appear only in assigned GO-TO statements 

** is the only valid exponentiation symbol 

ASCII FORTRAN debug statements are not recognized 

An initial comment statement will be recognized as the start 
of a module 
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ANALYZER COMMANDS 


A variety of coverage analysis reports can be generated from data 
collected during execution of a FORTRAN program that was instrumented by 
AVFS. (The INSTRUMENT option was discussed in Sec* 4.5.) Figure 6.1 
shows the execution coverage sequence. 

In order to proceed with instrumented software testing, the source 
text (which has been instrumented by AVFS) is compiled and executed. At 
program linkage time, any user externals necessary for execution of the 
instrumented code must be supplied. During test execution the program 
operates normally, reading its own data and writing its own outputs. 
The instrumented modules call the data collection routine as their test 
probes are encounted which records (on UNIT 12) the accumulated data on 
module DD-path traversals. 

Each test execution may consist of a number of test cases. The 
program identifies the end of each test case by executing a special call 
to the data collection routine. The identification calls are auto- 
matically inserted at the end of main programs. Other are inserted by 
direction of the user, via the TESTBOUND command, at instrumentation 
time as discussed in Sec. 4.5. 

The coverage reports are generated by a set of commands that 
differ slightly from the AVFS commands (Sec. 3, 4, 5); for this reason 
the ANALYZER commands are presented in this separate section. 
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There are two ANALYZER commands, an option selection and a module 
selection command. The type of report is specified by the command: 

OPTION {S> - <list> 

<list> may be one or more of the three options: SUMMARY, NOTHIT, or 

DETAILED. 

If the DETAILED option is specified, then the OPTION command must 
be preceded by one or more module selection commands: 

FOR MODULE {S> ** (<name-l>, <name-2>, ... <name-n>) 

<name> is the name of the module (subroutine, function or program). A 
maximum of 100 modules may be specified at one time. More than one FOR 
MODULE { S > command may be used to accommodate all specified modules. The 
DETAILED reports will be generated only for the modules named in this 
command which have been both instrumented and invoked. 

Since the Coverage Analysis program records execution trace data 
in internal tables, the amount of data recorded is limited by table 


size. The limitations are given below: 

Maximum number of modules to analyze 100 

Maximum number of test cases 10 

Maximum number of DD-paths to analyze 2000 

Maximum number of DD-paths not traversed 

in any test case 1000 
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6.1 SUMMARY 


The SUMMARY option produces a report which summarizes testing 
coverage for all instrumented and invoked modules. Figure 6.2 shows a 
sample SUMMARY report, which lists the following information: 

• Test case number 

• Module names and numbers of DD-paths 

• Number of module invocations, number of DD-paths traversed, 

and percent coverage for this test case 

• Cumulative number of module invocations, number of DD-paths 
traversed, and percent coverage for all test cases 

When multiple test cases are involved, the SUMMARY report shows data 
from the current test case and the immediately preceding test case. 
When the end of the trace data is encountered, a cumulative summary of 
all test cases is produced (Fig. 6.3). 

Command 


OPTION - SUMMARY 


Reports 


DD-path Summary 
Multiple Test Summary 


(Fig. 6.2) 
(Fig. 6.3) 
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6.2 NOTHIT 


The NOTHIT option requests a report which lists DD-paths not 
executed for all instrumented and invoked modules. Figure 6.4 shows a 
sample NOTHIT report, which lists the following information: 

• Module names 

• Test case number 

• Number of DD-paths not traversed, for this test case and for 
all test cases 

• DD-path numbers not traversed for this test case and for all 
test cases. 


Command 


OPTION =» NOTHIT 


Report 


DD-paths Not Executed 


(Fig. 6.4) 
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Figure 6.4 


DD-Paths Not Executed 





6.3 DETAILED 


The DETAILED option command selects a report which shows a 
breakdown of individual DD-path coverage. A single tes tease report like 
the one in Fig. 6.5 is generated for each specified module which was 
instrumented and invoked. Figure 6.6 shows the cumulative report, which 
is generated after the individual testcase reports. Both provide the 
following information: 

• Module name 

• Test case number 

• List of DD-path numbers, with an indication of those which 
were not executed, a graphical representation of the number 
of executions, and an itemized listing of the number of 
executions 

e Overall module coverage data 

Command 

FOR MODULES ■ (<name-l > ,<name-2> , . . .<name-n) 

Reports 

Single Test DD-path Execution (Fig. 6.5) 

Cumulative DD-path Executions (Fig. 6.6) 

Rule 

1. Maximum of 100 modules names specified. 

2. Repeat the module selection command as necessary; e.g., 

FOR MODULES » (<name-l > , . . . ,<name-i>) 

FOR MODULES = (<name-i+l > , . . . ,<name-n>) 

3. The module selection command must precede the DETAILED 

option. 
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Figure 6.5. Single Test DD-Path Execution 
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Figure 6.6. Cumulative DD-path Execution 
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The AVFS options are specified by a command file. For FORTRAN the 
command file contains the OPTIONS command as described in Section 3.3 or 
a UNIVAC executes statement. For AED the command file contains a UNIVAC 
execute statement. Sample command files are given in Appendix C. 
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APPENDIX A 


AVFS COMMAND SUMMARY AND CHECKLIST 


FORTRAN Commands 

Either an OPTION or REPORT command is required; the other commands 
are used when it is appropriate* They must appear in the order shown. 
Where an abbreviation is allowed, it appears to the right of the 
command; the appropriate UNIVAC run stream command is at the far right. 

RESTART REST @XQT,R 

RESTART instructs AVFS to use a saved restart file from a 
previous run. 

EXPAND EXPA @XQT,E 

EXPAND allows additional source to be added to a restart 
file. 

FILE, PUNCH ® <file number> FILE,PUNC=<f ile number> 

Instructs AVFS to reassign PUNCH; the default is UNIT 9. 

INSTRUMENT, PUNCH, PROBE, (<file number >) 

Instructs AVFS to reassign the data collection file. The 
default is UNIT 12. 

FIRSTLINE ■ (<run stream cotnmand>) 

Instructs AVFS to insert the given run stream command as the 
first line of each element. 


A-l 



OPTIONS=<list> 


OPTI = <list> 


<list> may contain one 
separated by commas: 

or more of 

the following options. 

LIST 

LIST 

<aXQT,L 

DOCUMENT 

DOCU 

@XQT , D 

SUMMARY 

SUMM 

@XQT,B 

STATIC 

STAT- 

@XQT,S 

INSTRUMENT 

INST 

@XQT , I 

INPUT/OUTPUT 

INPU 

@XQT , T 

REACHING SET 

REAC 

none 


REPORT - <list> REPO = <list> 

<list> may contain one or more of the following reports, 
separated by commas : 


REPORT 

MINIMUM 

REPORT 

NAME 

ABBREVIATION 

GENERATED 

COMMONS 

CO 

Commons Summary 

PROFILE 

PR 

Statement Profile 

INVOCATIONS 

L 

Entrys and invocation 
summary 

COMMONS /ENHANCED 

CO/E 

Common Matrices 

BANDS /n 

B or B/n 

Invocation Bands where n is 
the number of levels 

SPACE 

SP 

Invocation Space 

SYMBOLS 

SY 

Symbol Report 

READS 

R 

I/O Statements 

CROSS 

CR 

Symbol Cross Reference 

PICTURE 

PI 

Picture of module structure 
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FOR MODULE = (<namel>,<name2>, . • . . ) 
module selection command. 

TESTBOUND, MODULE * (<name>) , STATEMENT =* <number> 

Used with instrumentation command for setting test case 
boundaries . 

REACHING SET, MODULE » (<name>),TO ** <DD-path number>, 

FROM - <DD-path numb e r >{, ITERATIVE) 

When the option, REACHING SET, is used, it is necessary 
to specify one or more reaching sets with the above 
command. The use of ITERATIVE is optional; if present, 
an iterative reaching set is generated. 
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ANALYZER COMMANDS 


Selection of ANALYZER reports desired must be made by the user. 
The type or report is specified in the command, 

OPTION (S) =» <list> 


<list> may 

contain one 

or more of the following options, separated by 

commas: 




DETAILED 

DETA 


NOTHIT 

NOTH 


SUMMARY 

SUMM 


When the DETAILED option is listed, reports will be generated only for 
those modules that are listed in a command, 

FOR MODULE (S) - (< name- 1 >,< name-2 >, . . . ,<name-n>) • 

<name> is the name of the subroutine, function or program. This module 
selection conmand must precede the OPTION - DETAILED conmand. 
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AED COMMANDS 


@XQT GRC*LIST.LIST 

enhanced listing 

@XQT GRC*STATIC. STATIC 
static analysis 

<axqr GRC*CROSS. CROSS 

local cross reference 

@XQT GRC*SYMBOL. SYMBOL 
symbols report 

@XqT GRC*DEPEND. DEPEND 

module dependencies 

@XQT GRC*GLOBAL. GLOBAL 

global cross reference 

@XQT GRC*PROFILE. PROFILE 
statement profile 

@XQT GRC*UNITS. UNITS 

dimensional analysis 

@XQT GRC*TRACE. TRACE 

trace instrumentation 

@XQT GRC*ASSERT. ASSERT 

assertion instrumentation 
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@XQT GRC* INST. INST 

path instrumentation 

@XQT GRC*REACH. REACH 

reaching set generation 


@XQT GRC*VCG. VCG 

symbolic execution and verification condition generation 


@XQT GRC *TREE . TREE 

invocation hierarcy (calling tree) 


@XQT GRC*FLOW .FLOW 
f lowgraph 


@XQT GRC* INTER. INTER 

interface report 
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APPENDIX B 


FILE DESCRIPTIONS 


FILE 

NUSCER 

OATA 

STRUCTURE 

MODE 

(1) 

STORAGE 

(25 

RECCRO 

FORMAT 

RECOW END ED 
ALLOCATION 

USAGE 

(3) 

2 

1 fbrary 

8 

R 

system standard (4) 

scratch file 

R/X 

13 

workspace 

8 

R 

system standard (4) 

scratch file 

R/X 

4 

user com* ends 

H 

S 

card Image 

scratch file 

R/X 

3 

commands Input 

H 

S 

card Image 

system card reader 
permanent f I le 

R 

6 

reports 

rt 

S 

128 characters/ 
line maximum 

system printer 

X 

9 

Instrumented/ 

restructured 

source 

H 

s 

card Image 

scratch file 

R/X 

3 

source 

H 

s 

card 1 mage 

system card reader 
permanent file 

R 

8 

new restart 
fl te 

9 

s 

system standard 

permanent file 

X 

It 

old restart 
file 

8 

s 

system standard 

pcrmwenl file 

R 

12 

probe test 
data trace file 

B 

s 

system standard 

permaient file 

R 

Notes: 

(1) 8 * binary; H 

(2) R » random; S 

(3) R * read only; 

* character 

* sequential 
; R/X * read 

and/or write; 

X * write only 




(4) Installation dependent 



AED FILE DESCRIPTIONS 


FILE 

NUNBER 

DATA 

STRUCTURE 

MODE 

STORAGE 

FORMAT 

RECOMMENDED 

ALLOCATION 

5 

SOURCE 

H 

S 

CARD IMAGE 

STANDARD INPUT 

6 

REPORTS 

H 

s 

TEXT LINES 

STANDARD OUTPUT 

20 

TOKEN FILE 

H 

s 

TEXT LINES 

TEMPORARY 

25 

MULTI -MODULE 
INFO. 

H 

s 

TEXT LINES 

TEMPORARY 

30 

INSTRUMENTED 

CODE 

H 

s 

CARD IMAGE 

TEMPORARY 
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APPENDIX C 


JOB STREAMS FOR AVFS AT UNIVAC INSTALLATIONS 
AVFS INITIAL RUN - CREATES AN INTERFACE FILE 


@HDG ** 

@ASG ,A YOURSOURCE. 

@USE Y., YOURSOURCE. 

@ASG ,CP YOURFILE. ,F///400 
@USE 8., YOURFILE. 

@ASG,A GRC*AVFS . 

@USE R. ,GRC*AVFS. 

@ASG,T 2..F///1500 
<§ASG,T 13 . ,F// / 1500 
@XQT R.AVFS 

FOR MODULES'* (LIST OF MODULES). 
OPTION=STATIC . 

@EOF 

0ADD,P Y.PROCS 
@ADD,P Y. ELEMENTS 
@FIN 


AVFS INITIAL RUN ** 

YOUR FORTRAN OR SOURCE 

(OPTIONAL) CATALOG INTERFACE FILE 

ASG AVFS TRAN, ANALYZER 


EXECUTE AVFS 

(OPTIONAL) DEFAULT IS ALL MODULES 
ANY LIST OF VALID OPTIONS (SEC. 4) 

SEPARATES AVFS COMMANDS FROM YOUR 
SOURCE 

(OPTIONAL) ADD PROCS HERE 
ADD SOURCE ELEMENTS HERE 
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AVFS EXPAND RUN - EXPANDS AN INTERFACE FILE 


** AVFS EXPAND RUN ** 

. YOUR FORTRAN OR SOURCE 


@HDG 

@ASG,A YOURSOURCE. 

@USE Y., YOURSOURCE. 

@ASG,A YOURFILE. 

@USE 11., YOURFILE. 

@ASG,A GRC* AVFS . 

@USE R. , GRC* AVFS. 

@ASG,CP NEWFILE. 

@USE 8., NEWFILE. 

@ASG,T 2..F///1500 
@ASG,T 13., F/// 1500 

@XQT R.AVFS 

EXPAND. 

FOR MODULES=(LIST OF MODULES). 
OPTION=STATIC . 

@EOF 

@ADD,P Y.PROCS 
@ADD ,P Y. ELEMENTS 
@FIN 


ASG AVFS INTERFACE FILE (FROM 
PREVIOUS RUN) 

ASG AVFS, TRAN, ANALYZER 

NEW INTERFACE FILE 


EXECUTE AVFS (EXPAND PLUS OPTIONS) 

EXPAND INTERFACE FILE 

(OPTIONAL) DEFAULT IS ALL MODULES 

ANY LIST OF VALID OPTIONS (SEC. 

4.) 

SEPARATES AVFS COMMANDS FROM YOUR 
SOURCE 

(OPTIONAL) ADD PROCS HERE 
ADD SOURCE ELEMENTS HERE 
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AVFS 

RESTART RUN - USES AN INTERFACE FILE 

@HDG 


** 

AVFS RESTART RUN ** 

@ASG ,A 

YOURFILE. 

• 

AVFS INTERFACE FILE (FROM PREVIOUS 
RUN) 

@USE 11 

. , YOURFILE. 

• 


@ASG ,A 

GRC*AVFS. 

• 

ASG AVFS, TRAN, ANALYZER 

@USE 

R.,GRC*AVFS. 

• 


<§ASG,T 

2. ,F///1500 

• 


@ASG,T 

13. .F///1500 

• 


@XQT 

R.AVFS 

/ 

• 

EXECUTE AVFS USING A RESTART FILE 

RESTART 

• 



OPTION* 

STATIC. 

• 

ANY LIST OF VALID OPTIONS (SEC 4.) 

@FIN 
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AVFS INSTRUMENT, EXECUTE AND ANALYZE RUN 


@HDG ** 

@ASG,A YOURSOURCE. 

@USE Y . , YOURSOURCE . 

@ASG ,A GRC*AVFS. 

@USE R. ,GRC*AVFS. 

@ASG,T 2., F/// 1500 
@ASG,T 13. ,F///1500 
@XQT R.AVFS 
FILE, PUNCH® 10 . 

INSTRUMENT , PUNCH .PROBE , ( 20 ) . 

FIRSTLINE = (@FTN,S TPF$.+). 

OPTION = INSTRUMENT, LIST. 

TESTBOUND ,MODULE=(MAIN) , 

STATEMENT® 10. 

@ADD,P Y.PROCS 

@ADD ,P Y. ELEMENTS 

@EOF 

@ADD,P 10. 

@MAP 

@XQT 


AVFS INSTRUMENT, EXECUTE, AND 
ANALYZE RUN ** 

YOUR FORTRAN SOURCE 
ASG AVFS, TRAN, ANALYZER 


EXECUTE AVFS (INSTRUMENT AND LIST) 

PLACE INSTRUMENTED SOURCE ON UNIT 
10 

COLLECT DATA ON UNIT 20 
PREPARE SOURCE FOR ASCII COMPILER 
INSTRUMENT AND LIST 
TEST CASE BOUNDARY 

(OPTIONAL) ADD PROCS HERE 
ADD SOURCE ELEMENTS HERE 

YOUR INSTRUMENTED SOURCE IS ON 10. 

MAP FOR YOUR PROGRAM 

EXECUTE YOUR INSTRUMENTED PROGRAM 


( YOUR DATA ) 

@XQT R. ANALYZER . EXECUTE COVERAGE ANALYZER 

FOR MODULES® (LIST OF INSTRUMENTED ELEMENTS). 

OPTION=SUMMARY,NOTHIT, DETAILED. . ANY LIST OF VALID OPTIONS (SEC. 6) 

@FIN 
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AVI’S FLOWGRAPH ANALYSIS 


@HDG ** AVFS FLOWGRAPH ANALYSIS ** 

@ASG,A GRC*AVFS. 

@ASG,A YOURSOURCE. 

@ASG,T TEMP. 

@ASG,T 2. ,F40// / 1500 
@ASG,T 13. ,F40///1500 
@USE 8., TEMP. 

@XQT GRC*AVFS . AVFS 
OPTION = DOCUMENT 
REPORT - PICTURE 
@EOF 

@ADD ,P YOURSOURCE. 

@EOF 

@FIN 
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AVFS STATIC ANALYSIS 


@HDG ** AVFS STATIC ANALYSIS ** 

@ASG,A GRC*AVFS. 

@ASG,A YOURSOURCE. 

<§ASG,T TEMP. 

@ASG,T 2. ,F40///1500 
@ASG,T 13..F40///1500 
@USE 8., TEMP. 

@XQT GRC*AVFS . AVFS 

OPTION = STATIC 

FOR MODULES =» (MAIN , SORT , CALC ) 

0EOF 

@ADD,P YOURSOURCE. 

0EOF 

@FIN 
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AVFS REACHING SET ANALYSIS 


@HDG ** AVFS REACHING SET ANALYSIS ** 

@ASG,A GRC*AVFS. 

@ASG,A YOURSOURCE. 

@ASG , T TEMP. 

@ASG,T 2. ,F40///1500 
@ASG,T 13. ,F40/ //1500 
@USE 8., TEMP. 

@XQT GRC *AVFS . AVFS 
OPTION = REACH 

REACHING SET, MODULE = (SORT), TO = 7, FROM =3. 

@EOF 

@ADD,P YOURSOURCE. 

@EOF 

@FIN 
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AVFS INDENTED LISTING 


@HDG ** AVFS INDENTED LISTING ** 

@ASG,A GRC*AVFS. 

@ASG,A YOURSOURCE. 

@ASG , T TEMP. 

@ASG,T 2. ,F40/ / / 1500 
@ASG,T 13..F40///1500 
@USE 8., TEMP. 

@XQT GRC*AVFS .AVFS 
OPTION = LIST 
@EOF 

@ADD,P YOURSOURCE. 

@EOF 

@FIN 
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AVFS DOCUMENTATION 


@HDG ** AVFS DOCUMENTATION ** 

@ASG,A GRC*AVFS. 

@ASG,A YOURSOURCE. 

@ASG,T TEMP. 

@ASG,T 2.,F40///1500 
@ASG , T 13. ,F40/// 1500 
@USE 8., TEMP. 

@XQT GRC*AVFS .AVFS 
OPTION - DOCUMENT 
@EOF 

@ADD,P YOURSOURCE. 

@EOF 

@FIN 
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AVFS SUMMARY 


@HDG ** AVFS SUMMARY ** 

@ASG,A GRC*AVFS. 

@ASG , A YOURSOURCE. 

@ASG,T TEMP. 

@ASG,T 2..F40///1500 
@ASG,T 13. ,F40/// 1500 
@USE 8., TEMP. 

@XQT GRC*AVFS .AVFS 
OPTION =■ SUMMARY 
@EOF 

@ADD,P YOURSOURCE. 

@EOF 

@FIN 


C-10 



AVFS INDENTED LISTING 


@HDG ** AVFS INDENTED LISTING ** 

@ASG,A GRC*LIST. 

@ASG,A YOURSOURCE. 

@ASG,AX INSERTS. 

@XQT GRC*LIST.LIST 
@ADD,P YOURSOURCE. 

0FIN 
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AVFS SYMBOLS 


@HDG ** AVFS SYMBOLS ** 

@ASG, AX GRC*SYMBOL. SYMBOL 
@ASG,A YOURSOURCE. 

@ASG,T TKFIL. 

@USE 21., TKFIL. 

@ASG,AX INSERTS. 

@ASG,T LKFIL. 

@USE 22., LKFIL. 

@XQT GRC*SYMBOL. SYMBOL 
@ADD,P YOURSOURCE. 

@FIN 
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AVFS UNITS ANALYSIS 


@HDG ** AVFS UNITS ANALYSIS ** 

@ASG,A GRC*UNITS * 

@ASG,A YOURSOURCE. 

@ASG,AX INSERTS. 

@XQT GRC*UNITS. UNITS 
@ADD,P YOURSOURCE. 

@FIN 
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AVFS INTERFACE 


@HDG ** AVFS INTERFACE ** 

@ASG,AX GRC* INTER. 

@ASG,A YOURSOURCE. 

@ASG,T TKFIL. 

@USE 21., TKFIL. 

@ASG , AX INSERTS. 

@ASG,T LKFIL . 

@USE 22., LKFIL. 

@ASG,AX LIBOLD. 

@USE 11., LIBOLD. 

@CAT LIBNEW. 

@ASG,AX LIBNEW. 

@USE 8., LIBNEW. 

@XQT GRC*INTER. INTER 
@ADD,P YOURSOURCE. 

@FIN 
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AVFS CROSS REFERENCE 


@HDG ** AVFS CROSS REFERENCE ** 

@ASG,AX GRC*CROSS. 

@ASG,A YOURSOURCE. 

@ASG,T TKFIL. 

@USE 21., TKFIL. 

@ASG,AX INSERTS. 

@ASG,T LKFIL. 

@USE 22., LKFIL. 

@XQT GRC*CROSS. CROSS 
@ADD,P YOURSOURCE. 

@FIN 
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AVFS INVOCATIONS 


@HDG ** AVFS INVOCATIONS ** 

@ASG ,AX GRC*INVOKE. 

@ASG,A YOURSOURCE. 

@ASG,T TKFIL . 

@USE 21., TKFIL. 

@ASG,AX INSERTS. 

@ASG , T LKFIL. 

@USE 22., LKFIL. 

@XQT GRC* INVOKE. INVOKE 
@ADD,P YOURSOURCE. 

@FIN 
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AVFS DEPEND 


@HDG ** AVFS DEPEND ** 

@ASG,AX GRC*DEPEND. 

@ASG,A YOURSOURCE. 

@ASG,T TKFIL. 

@USE 21., TKFIL. 

@ASG ,AX INSERTS. 

<§ASG,T LKFIL. 

@USE 22., LKFIL. 

@XQT GRC*DEPEND. DEPEND 
@ADD,P YOURSOURCE. 

@FIN 
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AVFS TREE 


@HDG ** AVFS TREE ** 

@ASG,AX GRC*TREE. 

@ASG,A YOURSOURCE. 

@ASG , T TKFIL. 

@USE 21., TKFIL: 

@ASG,AX INSERTS. 

@ASG,T LKFIL . 

@USE 22., LKFIL. 

@XQT GRC*TREE.TREE 
<?ADD,P YOURSOURCE. 

@FIN 
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AVFS GLOBAL CROSS REFERENCE 


@HDG ** AVFS CROSS REFERENCE ** 

@ASG,AX GRC* INTER. 

@ASG,A YOURSOURCE. 

@ASG,T TKFIL. 

@USE 21., TKFIL. 

@ASG,AX INSERTS. 

@ASG,T LKFIL. 

@USE 22., LKFIL. 

@ASG , T FTN028. 

@USE 28..FTN028. 

@XQT GRC *GLOBAL. GLOBAL 
@ADD,P YOURSOURCE. FIRST 
@XQT GRC*GLOBAL. GLOBAL 
@ADD,P YOURSOURCE. SECOND 
@XQT GRC*GLOBAL. PRINT 
@FIN 
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AVFS STATEMENT PROFILE 


@HDG ** AVFS STATEMENT PROFILE ** 

@ASG,A GRC*PROFILE. 

@ASG,A YOURSOURCE. 

@ASG,AX INSERTS. 

@XQT GRC*PROFILE. PROFILE 
@ADD,P YOURSOURCE. 

@FIN 
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AVFS INSTRUMENTATION 


0HDG ** AVFS INSTRUKENTATION ** 

6ASG.A CRC*INST. 

$ASG.A INSERTS, 

QASG.T INSTFL. 

8USE 30, .INSTFL. 
gASG.T TABFIL. 
eUSE 25. .TABFIL. 

8ASG.A YOURSOURCE. 

@XQT GRC*INST • INST 
@ADD,P YOURSOURCE. 

6ASG.T PROBE. 

0ASG.A AUTO. 

0ASG.A ALTLIB*FTN. 

@ALTLIB*FTN.FTN,F AUTO. MAIN 
gPACK AUTO. 

@TPF AUTO. 

0PACK 

GPREP 

@USE 3., PROBE. 
gXQT AUTO. MAP 

<§COPY # I INSTFL . , YOURSOURCE . INSTFL 
0COPY.I PROBE. .YOURSOURCE. PROBE 

$CAPS*CROSS • AEDCAPS , SC YOURSOURCE . INSTFL , YOURSOURCE . INSTFL 

@CAPS*CROSS. AEDCAPS.SC YOURSOURCE. PROBE, YOURSOURCE. PROBE 

0CAPS*CROSS . CASM2 , S YOURSOURCE . INSTFL , YOURSOURCE . OB JNAM 

0CAPS *CROSS . CASM2 , S YOURSOURCE. PROBE, YOURSOURCE. DDPATH 

eCAPS *CRO S S . LINK , LRS I , YOURSOURCE . INSTFL 

ORIGIN OF PROGRAM 
INCLUDE FOR PROGRAM 

END 

QXQT CAPS*CROSS.HPLDTAPE 
YOURSOURCE . INSTFL 

?FIN 
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AVFS TRACE INSTRUMENTATION 


@HDG ** AVFS TRACE ** 

@ASG,A GRC*TRACE. 

@ASG,A INSERTS. 

@ASG,T INSTFL. 

@USE 30., INSTFL. 

@ASG,T TABFIL. 

@USE 25., TABFIL. 

@ASG, A YOURSOURCE. 

@XQT GRC*TRACE. TRACE 
@ADD,P YOURSOURCE. 

@COPY , I INSTFL . , YOURSOURCE . INSTFL 

@CAPS*CROSS . AEDCAPS , SC YOURSOURCE . INSTFL , YOURSOURCE . INSTFL 

@CAPS*CROSS . CASM2 , S YOURSOURCE . INSTFL , YOURSOURCE . OB JNAM 

@CAPS*CROSS.LINK,LRSI .YOURSOURCE. INSTFL 

ORIGIN OF PROGRAM 
INCLUDE FOR PROGRAM 

END 

@XQT CAPS*CROSS .HPLDTAPE 
YOURSOURCE . INSTFL 

@FIN 


C-22 



AVFS ASSERTION INSTRUMENTATION 


@HDG ** AVFS ASSERTION INSTRUMENTATION ** 

@ASG,A GRC* ASSERT. 

@ASG,A INSERTS. 

@ASG , T INSTFL. 

@USE 30., INSTFL. 

@ASG,T TABFIL. 

@USE 25., TABFIL. 

@ASG,A YOURSOURCE. 

@XQT GRC*ASSERT. ASSERT 
@ADD,P YOURSOURCE. 

@COPY,I INSTFL., YOURSOURCE. INSTFL 

@CAPS*CROSS .AEDCAPS.SC YOURSOURCE. INSTFL .YOURSOURCE. INSTFL 

@CAPS*CROSS . CASM2 , S YOURSOURCE. INSTFL .YOURSOURCE .OB JNAM 

@CAPS *CROS S . LINK , LRS I , YOURSOURCE . INSTFL 

ORIGIN OF PROGRAM 
INCLUDE FOR PROGRAM 

END 

@XQT CAPS*CROSS .HPLDTAPE 
YOURSOURCE . INSTFL 
@FIN 
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AVFS REACHING SET LISTING 

@HDG ** AVFS REACHING SET LISTING ** 

@ASG,A GRC*REACH. 

@ASG,A YOURSOURCE. 

@ASG,AX INSERTS. 

@XQT GRC*REACH. REACH 
@ADD,P YOURSOURCE. 

@EOF 

1 5 

@FIN 
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